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This publication describes the object-time 
PL/I Library package which forms an 
integral part of the PL/I processing 
system. General information covering the 
overall design and conventions is provided 
as well as information specific to the 
various areas of language support. 


The publication is intended primarily 
for technical personnel who wish to 
understand the structure of the library in 
order to maintain, modify, or expand the 
PL/I processing system. 
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The publication includes two 
introductory chapters, ‘The PL/I Library‘ 
and ‘General Implementation Features‘, 
which contain a general description of the 
library as a component of IBM System/360 
Operating System, and general notes on 
features of the operating system and the 
PL/I (F) Compiler that are used in the 
library implementation. The remainder of 
the manual describes the design of the 
library modules in relationship to PL/I 
language features, and indicates the use 
that is made of the control program to 
support the design. 


The descriptive material is supported by 
a set of module description summaries and 
several appendixes. The module summaries 
indicate the salient features of individual 
modules in the library package, and act as 
guides to the program listings that are 
available as part of the PL/I Library 
distribution. The appendixes contain 
details of the system macro instructions 
used, system generation, library 
pseudo-registers and macro instructions, 
library internal error codes and associated 
messages, and PL/I control blocks. 
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FUNCTION 


The PL/I library was designed as a set of 
reentrant load modules, each performing a 
single function or a group of related 
functions. 


The library modules can be divided into two 
groups: 


1. Those that act as an interface between 
compiled code and the IBM System/360 
Operating System; these modules are 
mainly concerned with input/output, 
dynamic program and storage 
management, and error and interrupt 
handling. 


2. Those that are closed subroutines 
specifically designed to perform 
arithmetic computations, data 
conversions, I/O editing and string 
generic built-in functions as the 
major part of their task. 


USAGE 


The linkage editor or linkage loader 
combines the object modules from a PL/I 
program with their required library modules 
to produce executable load modules. fhis 
is done by means of the external symbol 
dictionary (ESD) which resolves all direct 
references to the library modules by 
entry-point names (seven-character names) 
or, under certain circumstances, by module 
name (containing six characters). (See 
"Naming Conventions’ - Chapter 2) 


The library modules may in turn call 
other, secondary, library modules (e.g. as 
in data conversion). To ensure that only 
the ones required are called, any library 
object module that calls a secondary module 
is preceded by a linkage-editor LIBRARY 
statement. This statement specifies that 
the references to the secondary modules 
(which are seven-character entry-point 
names) should not be resolved unless the 
secondary modules are already part of the 
input to the load module. For any such 
secondary modules called, the compiler 
generates an ESD in which the references 
are six-character module names. 


The PL/I library acts as the sole 
interface between compiled code and the 
operating system. The compiled code does 
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not issue SVCs or system macro instructions 
but instead issues a library call. | 
Although the library module(s) called can 
issue an SVC instruction, it is more 
convenient to use system macro 
instructions. This method means that when 
the operating system changes, only the 
library module is rewritten, with the call 
to the library .from the compiler remaining 
as before. Similarly, if the svc calling 
sequence changes, the system macro is 
changed accordingly and the library module 
need only be reassembled. 


For further details on macro 
instructions, see IBM System/360 Operating 
System: Supervisor and Data Management 
Macro Instructions. The system macro 
instructions used by the library are listed 
in Appendix A. 


The PL/I library for each version of the 
F compiler is compatible with previous 
versions only. For example, whilst a 
module compiled under Version 2 can be 
link-edited and executed by an operating 
system that includes the Version 3 | 
compiler, the reverse is not possible. 


User-designed modules can be substituted 
for library modules; each user module is 
given the name of the library module it is 
meant to replace. 


Link Library 


Certain modules are loaded dynamically 
during program execution. These modules 
reside in the link library (SYS1.LINKLIB); 
they are transient modules and are loaded, 
when required, by the system macros LINK, 
LOAD and XCTL. DD statements are not 
required. The link-library modules are 
marked * in Appendix G; they comprise: 


1. The print and message modules of the 
error and interrupt handling 
subroutines. 


2. The modules for opening and closing 
files. 


3. The record-oriented I/O transmission 
modules. 


GY. Special multitasking modules. 


These modules can be replaced by 


user-designed modules, if required. The 
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user module is placed by the linkage editor 
into a partitioned data set (PDS); this 
data set must be described in a JOBLIB DD 
statement. 


All library modules normally residing on 
SYS1.LINKLIB may be made resident in the 
system when operating under MFT II or MVT. 


In an MFT II system, the resident area 
is effectively an extension of the nucleus; 
in an MVT system, the resident area is a 
section of the high order main storage 
called the LINK PACK AREA (LPA). 


Load Library: all other library modules are 
" link-edited with compiled code by the 
linkage editor. These modules reside on 
SYS1.PLILIB, and, normally, they may not be 
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resident in the system. However, the new 
shared library feature permits selected 
combinations of modules to be made resident 
by combining them into a load module (for a 
discussion on the shared library feature, 
see Appendix B). 


INSTRUCTION SET REQUIREMENTS 


The universal instruction set is generally 
required for the execution of PL/I 
programs. It is possible that 
floating-point or decimal instructions may 
be used in the execution of programs that 
do not use floating-point or decimal data. 


NAMING CONVENTIONS 


PL/I library external names always begin 
with IHE; this is followed by two, three or 
four characters, according to the name 
function (see Figure 1). 


REGISTERS: SYMBOLIC NAMES 


The following symbolic names are used in 
the library modules for general registers 
0-15: 


Symbolic Symbolic 
Register Name Register Name 
0 RO 8 RH 
1 R1,RA 9 RI 
2 RB 10 RJ 
3 RC 11 RX, WR 
4 RD 12 PR 
5 RE 13 DR 
6 RF 14 LR,RY 
7 RG 15 BR,RZ 


The following symbolic names are used 
for the floating-point registers: 


Symbolic 

Register Name 
FA 
FB 
FC 
FD 


ON Oo 
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LINKAGE CONVENTIONS 


Linkage between modules generally follows 
the operating system standard calling 
sequence. The main features of this are: 


1. Arguments are passed by name, not by 
value. The addresses of the arguments 
are passed, not the arguments 
themselves. 


2. These addresses are stored in a 
parameter list. 


3. The address of the list is stored in 
register RA. 


Full details are provided in IBM System/360 


Operating System: Supervisor and Data 
Management Services. 


Some PL/I Library modules, however, are 
called by a PL/I standard calling sequence. 
The main features of this are: 


1. Arguments are passed by name. 


2. Arguments are passed in general 
registers. 


This standard can only be used where the 
number of arguments is both fixed and less 
than eight. If these conditions are not 
met, the operating system standard is used. 


Two PL/I Library modules, IHESA and 
IHETSA, do not use either of these 
standards. The subroutines in these 
modules pass arguments by value as well as 


GSAS GS: SORES a a a ar aca Gos Se eee an 
[Number of |Format | Use | Meaning [ 
jCharacters| | | | 
wa - == ~- ~~~ -- f --- + = = $$ == nnn fn nnn nn nnn nnn nnn 
| 5 {IHEXX | | | 
{ { |Module name i 
| 6 | THEXXX | |XXX are chosen for mnemonic l 
}-~---——---} --——- - -- $ —-- - - - - - + - = = -jidentification of function. i 
| 6 JIHEXXX | PL/I Library defined macros | { 
}-----—----}-------} ------—-------------------}------—---------------~--------------—--+4 
] 7 | IHEXXXX | Entry-point name {First six characters are module name; i 
| l | [the seventh identifies the entry point | 
: { : |within the module. 

—_ 2) on ee ow ee oe eee eee eee ae ae een ep ee eee oe ee ee ee es ee ee ee ee ee > ee ee ee oe ew ee a a (eee ow EE Ow om a ae Oe a 8 OF © a 8 Se OD ee Oe oe Oe ee ee a ee eee 4 
; 7 | IHEQXXX|Pseudo-register name {XxX are chosen for mnemonic | 
| | | jidentification of function. (See | 

Appendix C.) 

on a ee See sc ee 
Figure 1. External Names used by the PL/I Library 
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by name, and pass them in parameter lists 
and in general registers. 


In general, whichever standard is used, 
whenever one module links to another a save 
area must be provided for the contents of 
the registers used by the called module. 
The save area procedure is: 


1. The calling module provides a standard 
save area (SSA) for the called module. 
The address of this save area is 
stored in register DR. 

2. If the called module in turn calls 
another module, it provides that 
module with a save area. Register DR 
now contains the address of this new 
save area. The save areas are chained 
together by the chain-back address 
field in the new save area. 


3. On return to the calling module, the 
following will be unchanged: 


Registers RB through LR 
Program mask 


Program interrupt control area 
(PICA) 


while the following may be changed: 

Registers RO, RA, and BR 

Floating-point registers 

Condition code 

The standard save area is a 72-byte area 

in which the contents of all the general 
registers can be saved. The format is 
described in Appendix H. 


The library does not support 
inter-module trace. Therefore: 


1. The chain-forward field in the SSA is 
not set. 


2. Calling sequence and entry-point 
identifiers are not employed. 


CODING CONVENTIONS 


Because all modules within the PL/I Library 
are coded to be reenterable, the following 
coding constraints must be observed: 

1. The modules are read-only. 


2. Workspace (for save areas and 
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temporary work areas) is obtained 
within an area dynamically allocated 
at program initialization or by a call 
to the Get VDA (variable data area) 
subroutine in IHESA. (See ‘Library 
Workspace’ in this chapter and in 
Chapter 4.) 


LIBRARY MACRO INSTRUCTIONS 


Seven macro instructions are available for 
use in the library modules. To obtain 
these macro instructions, use PL/I (F) 
SYMLIB tape 360S-LM512 XT05-00 and IEBUPDTE 
to create a partitioned data set named 
SYS1.PVTMACS. SYS1.PVTMACS should then be 
concatenated with SYS1.MACLIB (the 
partitioned data set containing the 
standard system macro instructions used by 
the operating system). 


Five of the seven macro instructions, 
IHEEVT, IHELIB, IHEZAP, IHEXLV, and IHEZ2ZZ, 
set up symbolic definitions in the program 
listing and the other two, IHESDR and 
IHEPRV, set the current addresses of the 
standard save area and the pseudo-register 
vector (PRV) respectively. The library 
macros are described in Appendix D. 


DATA REPRESENTATION 


Three types of data may exist within a PL/I 
program: 


1. Arithmetic 
2. String 
3. Statement-label 


The internal representation and other 
details of these three types are shown in 
Figures 2, 3, and 4. The invocation count 
used in the statement-label data 
representation is described in Chapter 4. 


Arithmetic or string data may be 
specified with the PICTURE attribute. A 
PICTURE arithmetic data item is called a 
numeric field and is represented internally 
as a character string. An arithmetic data 
item without a PICTURE attribute is called 
a coded arithmetic data item (CAD) and is 
represented internally in one of three 
System/360 formats: 


Fixed-point binary 
Floating-point 
Packed decimal 


{| Data Type | Implementation | 


~----y---—--}-----—------------ a-y----=~------- 7 ------------------------- 4 

















[Scale| Base |Precision| Internal | Alignment | Processing | 

| | format | | | 
p---~—-4-------1~~-—----- t+ +--+ + + ++ + +--+ b+ - +--+ +--+ = - + =| 
REAL data 
bp p= an nnn nn nnn nnn nt nn nnn 
|. {Binary | Peg |Fixed-point|p>15: Word Jarithmetic Operations are performed | 
| l |Max ps: 31|binary jpsi5: Half- Jon p-digit integers: scale factor q _ | 
| | | | | word jis specified in a DED. (See Appendix | 
| | | | | |H, ‘Data Element Descriptor’. ) [ 
| Fixed }-- man — fn a fa 
| |Decimal | P,q |Packed dec-| Byte |The p digits occupy FLOOR ((p + 2)72)| 
| | |Max p: 15]|imal | |bytes. Arithmetic operations as for | 
| | | (see ; | [fixed bindry | 
l | note) | | | | 
t-----+---—---}+-----—-- }-~---------}-------------}--------------~----------------------{ 
| {Binary | p |ps21: Word | | 
{ | |}Max ps: 53] |p>21: Double-| | 
| | i |Hexadecimal | word jThe data is normalized in storage | 
| Float }-- -+--------- 4{floating- }-------------jbefore and after arithmetic operat- | 
| | Decimal | p | point jps6: Word jions. | 
| i |Max ps 16] |p>6: Double-| | 
{ | | | | word | | 
}~-~~-4-------1-------+- 4 +--+ - + bd +e = + +--+] 
| COMPLEX data l 
bap npn ae nnn in nn nnn nnn nn 
| |Binary | Peq |Fixed-point|p>15: Word [As for real fixed binary. The real | 
; | [Max p: 31|binary [p<s153; Half- jand imaginary parts occupy adjacent | 
| | | | | word |fullwords or halfwords, with the | 
] | | | jreal part first. i 
| Fixed }-- ~}-~-~~--~- 4---—~----~ -+ }- - --- - - - ~~ - — f ~ nn e 
| | Decimal | P,.q |Packed dec-| Byte JAs for real fixed decimal. The real | 
{ | {Max ps 15]imal | Jand imaginary parts occupy adjacent | 
| | ] | { |fields, with the real part first. | 
}-----+---—--------—--- }----------- $------------- }---~-------------------------—------ { 
| {Binary | p |ps21: Word {As for real float binary. The real | 
| j jMax p: 53] |p>21: Double-|and imaginary parts occupy adjacent | 
| | ] [ | word {fullwords or doublewords, depending | 
| | | ; { Jon the precision, with the real part | 
| j | | Hexadecimal | | first. | 
| Float }-- —}------—---{floating- [}|--------~-~--4}-—---+-—--—~--———~-+~ +--+ = - |] 
| {Decimal | p jpoint [ps6: word [As for real float decimal. The real | 
| i jMax p: 16] [p>6: Double-|and imaginary parts occupy adjacent | 
| [ | | | word |fullwords or doublewords, depending | 
| | j | | [on the precision, with the real part | 
| | | | |first. | 
Pose Cee een he teins is as ce a a a a ae 


Note: When p is even, the effective precision for all arithmetic operations except div- 
ision is (p + 1,q), except when the SIZE condition is being checked. When this 
occurs, the first digit in the high-order byte must be checked to ensure that it 
is zero. 


Figure 2. Arithmetic Data Representaton 


0 7 8 31 COMMUNICATION CONVENTIONS 

eee qe ap ee a ae ee a a ee ee a oo ee Ss Se a ee ee Pee ee ee ee 

{ Invocation Count | 

boa nan nnn nnn nnn - - - --- - - | The use of library modules in a PL/I 

| | A(Statement label) | progran requires that: 

beeen do eee ee eed 
Figure 3. Statement-Label Data 1. Working storage be provided for the 

Representation modules. 
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Inplementation | 


| 
|\Data type}---------------7----------------+-- 


er ge gn ree a ee ee ae ee ee ee ee eee 5 econ 
|Representation ! Length | nile onel 
| Bit |1 binary digit | H Byte 1 
| jper bit™ |Maximum length: 32,767. If a VARYING attribute is | (see note) | 
}—-—--—-—-—-——}-—- -------------jdeclared, naxinun length is jieclared length, | --~-------| 
|Character|1 character per|regardless of the string value. | Byte | 
| | byte | 
loo eee a he ee eee sae ace aca a ee Dee J 


Notes The string occupies CEIL (n/8) bytes. If the string comes within the scope of an 
UNALIGNED attribute, the address of the first bit is provided by a byte address and 
bit offset in an SDV. (See ‘String Dope Vector’ in Appendix 4H.) 


Figure 4. String Data Representation 


2. Techniques for passing information 
about arguments and program status be 
provided. 


Working storage is obtained as library 
workspace (LWS). Appendix H gives the 
format of LWS, which is allocated by the 
library program management modules IHESAP 
and IHETSA. 


Two modes of communication are available 
for passing information: 


Uses parameter lists and 
registers. (See ‘Linkage 
Conventions‘. ) 


Explicit: 


Uses pseudo-registers or a 
Library communication area. 


Implicit: 


Some library modules are interpretive 
(as opposed to declarative), and 
accordingly require that information 
regarding the characteristics of their 
arguments be supplied. Such information is 
made available to the library in the form 
of standardized control blocks. The forn 
- and content of the compiler-generated 
control blocks in general use throughout 
the implementation are described in 
Appendix H; one or more blocks is required 
according to the nature of the data passed: 


Scalar arguments: 
Data element descriptor (DED) 
String dope vector (SDV) 
Symbol table (SYMTAB) 


Array arguments: 
Array dope vector (ADV) 
String array dope vector (SADV) 


Structures: 

Structure dope vector 

Dope vector descriptor (DVD) 
Formats: 

Format element descriptor (FED) 
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Special-purpose control blocks, such as 
the file control block (FCB), are described 
in Chapters 3, 4, and 5, and in Appendixes 
I, J, and K. 


Pseudo-Register Vector (PRV) 


This is an area of task-oriented storage, 
addressed through register PR. The PRV 
contains a number of pseudo-registers which 
effectively operate as implicit arguments 
and give information about, for example, 
current program status. All references to 
specific pseudo-registers within the PRV 
are made by the addition of a fixed 
displacement to the PRV base address in 
register PR. 


A pseudo-register is defined within a 
library module as a Q-type address constant 
which is fixed during the linkage editing 
process. All pseudo-register address 
constants within the PL/I implementation 
are two bytes long. The maximum size of a 
PRV is 4096 bytes. The pseudo-registers 
used by the PL/I Library are shown in 
Appendix Cc. 


Library Workspace (LWS) 


Various library modules require working 
storage: 


1. For internal functions. 


2. For Linkage to other modules. (A 
register save area must be provided.) 


Since the library is designed to function 
within a multitasking environment, such 
storage must be allocated ona 
task-oriented basis. The storage so 
allocated is termed library workspace 
(LWS). 


Library modules which use LWS refer to 
it by means of the PRV. A group of 
pseudo-registers in the PRV is set during 
LWS allocation to contain the addresses of 
contiguous areas within LWS. (See Appendix 
H.) Each of these areas is at a different 
level. 


The notion of level exists because of 
inter-module linkage between library 
modules: 


1. A module which invokes no other 
modules is assigned level 0. 


2. A module which invokes other modules 
is assigned a level number greater 
than the level number of any invoked 
module. 


3. A module which transfers control to 
another module (i.e., does not expect 
a return) is assigned the level number 
of that module. 


Invocation of the error-and-interrupt- 
handling subroutine is not considered 
sufficient to raise the level number of the 
invoking module, since the error subroutine 
uses a special level. 


Library workspace is allocated as 
primary or secondary LWS. 


Primary LWS is allocated during program 
initialization, before control is passed to 
the main procedure. fhe storage thus 
obtained is not freed until the PL/I 
program is finished. 


Secondary LWS is allocated for special 
purposes during program execution and is 
freed when the situation for which it was 
created no longer exists. It is allocated: 


1. When an on-unit is entered from a 
library module. This may lead to a 
recursion problem: library modules) 
called may overwrite this LWS. To 
avoid this, the existing LWS is 
stacked, a new one obtained and all 
the LWS pseudo-registers updated. 


2. When SNAP, system action or error 
messages are to be printed. The PRINT 
subroutine may overwrite the existing 
LWS: to avoid this, the same procedure 
is followed as for an on-unit. 


The library program management module 
IHESAP controls the allocation of LWS and 
the setting of library pseudo-registers. 
(See Chapter 4.) The library macro IHELIB 
controls the length of LWS and of each area 
within it. The LWS format can be changed 
by changing IHELIB and reassembling IHESAP. 


IHEPRV: 


Modules using specific areas in LWS 
address these areas by the following 
library macros: 


Used to address the LCA or when 
using an area as temporary workspace. 


IHESDR: Used when a module requires a 


standard save area for a module it is 
calling. 


Library Communication Area _ (LCA) 


Within the area allocated for library 
workspace is an area in which various 
symbolic names are defined. These names 
are used for implicit communication between 
library modules (mainly the data conversion 
modules). This area is the library 
communication area (LCA); its format and 
the usage of the symbolic names are shown 
in Appendix H. The LCA address is stored 
in the pseudo-register IHEQLCA. 


In the LCA there is a doubleword 
immediately before the first symbolic name. 
This contains (in the first four bytes) the 
address of the prior generation of LCA 
within a given task. This field is used to 
readdress the LCA which existed before an 
ON block was entered. IHEQLCA contains the 
address of the first symbolic name. 


Object-Time Dump 


A PL/I user may obtain a dump at any time 
by calling one of the following: 

IHEDUMC: Dump current task and then 
continue execution. 
IHEDUMJ: Dump all tasks and then continue 
execution. 

IHEDUMP: Dump all tasks and terminate 
major task (i.e., terminate the 
job step). 

IHEDUMT: Dump current task and then 
terminate it. 


Identification of required information 
(such aS save~area locations) in the dump 
is difficult because this information is 
not necessarily stored in locations 
arranged in a chronological sequence. To 
facilitate reading the dump, therefore, two 
subroutines, IHEZZC and IHEZZF, are 
provided. They extract certain information 
(chiefly about save areas and opened files) 
and print it as an index to the dump. Full 
details of this information are givén in 
Appendix F. 
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If a DD card exists, the information 
will be printed on the PL1IDUMP file (unless 
there is something wrong with the PL/I 
save-area chains, in which case the 
SYSABEND or SYSUDUMP file will be used). 

If the data set specified is other than the 
SYSOUT file, DISP=MOD should be used on the 
DD card. If there is no DD card and the 
operating system has the primary control 
program or MFT, only the normal indicative 
dump will be provided; in an MVT 
environment, if there is no DD card, there 
will be no dump at all. 


Checkpoint/Restart 


In an operating system with PCP, MFT II or 
MVT, a PL/I user may establish a checkpoint 
at any point within a job step by calling 
IHECKPS or IHECKPT. If IHECKPT is called, 
he must include a DD statement with the 
ddname SYSCHK to define the data set on 
which the checkpoint information is to be 
saved. If IHECKPS is called, any ddname 
may be used for the same purpose. 


Normally, the automatic restart function 
restarts the program at the most recent 
checkpoint whenever an abnormal termination 
occurs. If, however, a restart is to be 
forced by the user, CALL IHEREST must be 
specified. Alternatively, the automatic 
restart function can be disabled by the 
statement CALL IHERESN. This statement 
disables the automatic restart for any of 
the checkpoints if it is enabled; if it is 
already disabled, then it is considered and 
treated as a NOP. 


Automatic restart can be re-established 
by issuing a call to the checkpoint modules 
IHECKPT and IHECKPS. 


The module IHECKP is called directly 
from compiled code. It obtains an ordinary 
VDA for use aS a save area, rather than 
using library workspace, because the CHKPT 
macro instruction that is issued by IHECKP 
makes use of the first byte of the save 
area; the first byte of a save area in LWS 
is used for PL/I information. (Refer to 
Chapter 4 for a discussion of the VDA and 
LWS VDA.) Each time IHECKP is called, it 
creates, from a dummy held as part of the 
module, a DCB that refers to the data set 
defined by the ddname specified as a 
parameter to IHECKPS. As well as the 
address of the DCB, the checkpoint 
identifier specified for IHECKPS is also 
passed to the IHECKPT routine. 
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Sort/Merge - PL/I Interface 


A PL/I procedure may call the operating 
system Sort/Merge program, using the 
library module IHESRT. The publications in 
which the operation of Sort/Merge is 


described are: IBM System/360 Operating 
System: Sort/Merge, Form C28-6543, and, 


Sort/Merge Program Logic Manual, Form 


Four entry points, IHESRTA, IHESRTB, 
IHESRTC, IHESRTD are provided to enable use 
to be made of Sort/Merge user exits E15 and 
E35 to call PL/I procedures, as required by 
the application. 


Sort/Merge control statements are 
supplied as arguments to the PL/I CALL 
statement. These arguments correspond in 
format to standard Sort/Merge control 
statements, from which the parameter lists 
are generated. 


These arguments also specify the PL/I 
entry points to be invoked by the user 
exits E15 and E35, and any return codes to 
be used for inter-program communication. 


The normal library conventions for 
save-area chaining are not used for this 
module. Instead the module allocates a DSA 
(with code X‘'80° in the first byte). This 
is to ensure that if either user exit is 
used, the chain-back is through the DSAs 
only. 


After the parameter list for Sort/Merge 
is generated, the following actions are 
performed before linking to Sort/Merge: 


1. The registers in the external save 
area of the PL/I procedure are saved 
and replaced by special registers 
which are used in terminating the sort 
when: 


a. A PL/I exit procedure is 
terminated, due to an error, before 
the sort has terminated, or 


b. A GO TO from an exit procedure toa 
procedure at a level equal to, .or 
higher than, the calling procedure, 
occurs. 


Otherwise the PL/I procedure would 
terminate allowing the operating 
system to regain control, either 
directly or indirectly, while the link 
to Sort/Merge is still operative, with 
a resultant system interrupt. The 
registers stored in the special save 
area cause the calling procedure to 
enter ITHESRT and. complete the 
Sort/Merge operation. Any user exit 
calls to the now non-existent PL/I 


exit procedures are deleted, before 
restoring the external save area and 
returning control from the PL/I 
procedure. 


2. The PICA is set to system action for 
program interrupts. 


3. Register 13 is set to a special save 
area with a chain back address of 
zero. 


On normal completion of the sort, the 
PICA and external Save area are reset to 


the conditions at entry to IHESRT and 
control is returned to the calling program. 


If an exit is taken, the PL/I 
environment is reestablished and register 
13 is reset to the DSA allocated for 
IHESRT. The exit procedure is then invoked 
and thus the DSA chain is correct. 


Before returning to Sort/Merge the PICA 
and register 13 are reset to their values 
on initial entry to the exit routine in 
IHESRT. 
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CHAPTER 3: INPUT/OUTPUT 


FILES AND DATA SETS 


Within this publication, the term ‘data 
set' refers to a collection of records that 
exist on an external device. A file is 
known as such only within a program; it is 
possible that, within a given program, 
several files will use the same data set 
concurrently (direct access only). 
Similarly, a data set may be used by 
several programs, either concurrently or 
successively. 


The relationship between a file and a 
data set is established when the file is 
opened. The data set to be associated with 
a file is identified by the TITLE option. 
If this option is omitted or an implicit 
open occurs, a default identifier is formed 
from the first eight characters of the file 
name. The data set identifier is not the 
data set name, but the ddname (i.e., the 
name of the DD statement). Error messages 
which are related to file operations use 
the full file name (1 through 31 
characters). 


The attributes of a file in some 
instances restrict the attributes of its 
associated data set, but in those instances 


where device independence is possible, the 
full capabilities of the job control 
language DD statement are available. Unit 


assignment, space allocation, record format 
and length, and various data management 
options (such as write-verify) are 
established on a dynamic basis. 


DCLCB PRV 

0 31 0 31 
(SS ee ee 1 (Ses ee eae 
| PRV offset | | | | 
}-----7------ ; | | 
| | | | | 
| | (SaSS eS Ss—s45S4-52 | 
| L_---———-——-— +-—--->| A(FCB) } 
| | p—~—-—--- = ----------f 
| | | | 
| | | | 
| | | | 
| | | | 
| | | | 
Ea eee ete eee Ren ee J Leche eeseuseeoeuee ee j 
Figure 5. File Addressing Scheme 
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FILE ADDRESSING TECHNIQUE 


In order to accommodate reentrant usage of 
a PL/I module, which may imply that the 
module exists in read-only storage, the 
following technique is employed to 
communicate file arguments. All calls from 
compiled modules to the library involving 
file arguments address a read-only control 
block, the DCLCB. The library, using a 
field within this control block, is abie to 
address a cell within the pseudo-register 
vector generated for the task. This cell, 
the file register, in turn addresses a 
dynamically allocated control block, the 
file control block (FCB). (See Figure 5.) 


This control block, generated during 
compilation, contains information derived 
from a file declaration (either explicit or 
contextual). In addition, it contains the 
offset within the PRV of the file register, 
a fullword pseudo-register employed within 
the file addressing scheme. This 
pseudo-register contains the address of a 
dynamic storage area containing a file 
control block. The DCLCB is read-only, and 
thus permits compiled programs to exist 
within a reentrant environment (which may 
imply that the program is loaded into 
supervisor protected storage). The maximum 
length of a DCLCB is 56 bytes. 


File attributes specified within the 
DCLCB may he supplemented, but not 
overridden, by attributes specified in the 
OPEN statement which opens the file. An 


FCB 

0 31 
(eee (re ee ee 1 
| | 
| | | 
| | | 
| | | 
-4 
aan cea pean { 

| A(DCLCB) | 
[------------------- { 

| | 

| | 

| 

a es ee se J 


exception to this rule is the LINESIZE 
option, which overrules record length 
information declared in the ENVIRONMENT 
_attribute. | 


The format of the DCLCB is described 
fully in Appendix I. 


File Control Block (FCB) 


This control block is generated during 
program execution when a file is opened. 
Dynamic allocation of the FCB storage is 
required in order to accommodate reentrant 
usage of a given module, for the FCB is not 
read-only. The FCB contains fields for 
both the PL/I Library and for operating 
system data management. The initial 
portion of an FCB is PL/I-oriented, while 
the second portion is the DCB required by 
data management for all data set 
operations. The PL/I portion, called the 
DCB-appendage, is described in Appendix I; 
details of the various DCB constructions 
are available in the following IBM 
publications: 


IBM System/360 Operating System: System 
Control Blocks 


IBM System/360 Operating System: 
Supervisor and Data Management Services 


IBM System/360 Operating System: 


Supervisor _ and Data Management Macro 
instructions 


IBM System/360 Operating System: System 
Programmer's Guide 


PRV 
Go a ee ye 
| | 
| | 
Spat tite, ce { 
IHEQFOP | bo eae eee ee 
-------------- 
[ ; FCB1 
{ { pron 7 S-- 
| l | | 
| | | | 
| | Gomeeecamaens { 
[ | i 0 | 
| | bo---- = ----- { 
Was oss ese ce eee [ i 
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An FCB is generated for each file opened 
within a program; an FCB cannot exist for 
an unopened file. FCBs are generated in 
task-oriented storage (in the same subpool 
as the PRV for the task: subpool 1). 


Accordingly, if a file is implicitly 
closed because of the termination of the 
task that opened it, its FCB is freed and 
the file register is set to zero. The 
contents of a given file register ina 
non-opening upward task are zero. 
Subsequent reference to the file may cause 
the file to be reopened. (A non-opening 
upward task for a given file is a task that 
does not open the file, and which is not a 
subtask of a task that has opened the 
file.) 


When a file is opened, its generated FCB 
is placed in a chain which links together 
(through the TFOP field in the FCB) all 
files opened in a given task. When files 
are closed, they are removed from the 
chain. This chain, which is anchored in 
the PRV cell IHEQFOP, exists in order to 
perform special PL/I closing processes at 
task termination (whether normal or 
abnormal). When a task terminates, the 
object-program housekeeping routines 
determine which files are currently opened 
by this task. This is performed by the 
relevant housekeeping module calling 
IHEOCLD (close), which scans the chain and 
calls IHECLTB to close all files opened in 
the current task. If the cell IHEQFOP is 
zero, then no files are, at present, opened 
by the task. When a subtask is attached, 
this cell is initialized to zero in the 
newly generated PRV. The IHEZFOP chain is 
shown in Figure 6. 


Since an FCB is generated in dynamic 
storage, its address cannot be determined 
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Note: The FCBs are opened in the order 1, 2, 3, etc. 


Figure 6. Format of the IHEQFOP Chain 
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either at compile time or link-edit time; 
it is this characteristic of the FCB which 
requires the file addressing scheme 
outlined above. If a given procedure is 
being executed by two or more jobs 
(multi-jobbing), an FCB (with its 
associated PRV) exists for each job; the 
procedure does not, however, necessarily 
Operate on different data sets. Similarly, 
if a file is opened in two parallel 
subtasks, an FCB exists for each task. 


Program Execution 


When program execution is initiated, the 
PRV (including all file registers) is 
initialized to zero. When a file is opened 
(prepared for I/O operations), its 
associated file register is set to address 
an FCB; similarly, when a file is closed 
explicitly, its file register is again set 
to zero. 


Since a copy Of the PRV of the attaching 
task (calling procedure) is provided to the 
attached task (called procedure), the state 
of a file is communicated downward through 
major to minor tasks. If the file is not 
open, the file register remains zero. If a 
file has gone through the opening process 
but has failed to be opened (UNDEFINEDFILE 
condition), the high-order byte (bits 0 to 
7) of the file register will contain an 
error code that indicates the cause of 
failure. The codes consist of two 
hexadecimal digits; they are shown in 
Figure 7. 


If the file register is non-zero, the 
file is open and its FCB is also available 
to all the subtasks created while the file 
was in the open state. This technique of 
communicating the state of a file makes it 
possible to access a file in two parallel 
subtasks. 


Two advantages of the use of the DCLCB 
in the file addressing scheme are: 


1. Because the DCLCB, in conjunction with 
an implicit opening statement, 
provides all the information necessary 
to open a file, a file can be opened 
by I/O statements other than the OPEN 
statement. 


2. Because the DCLCB is part of the 
static storage of a load module, its 
address is constant throughout program 
execution. This address can be used 
therefore as the file identification 
in ON conditions that relate to files. 
ON conditions may be enabled for a 
file before it is opened, since the 
DCLCB address is always available. 
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[SSS a aa Raa a 1 
| Error | | 
| code | Meaning | 
}------- }-~-------------------~------------ 4 
| 81 | Conflict between DECLARE and 
| | OPEN attributes | 
| | | 
| 82 | File access method not | 
| | supported { 
| | | 
| 83 | No block size | 
| | | 
| 84 | No DD card | 
| | | 
| 85 | TRANSMIT condition while | 
i | initializing data set (only | 
| | applicable to DIRECT OUTPUT | 
| | REGIONAL files) | 
{ | | 
| 86 | Conflict between PL/I | 
| | attributes and environment { 
| | options | 
i | | 
| 87 | Conflict between environment | 
| | options and DD parameters | 
| | | 
| 88 | Key length not specified | 
| | | 
| 89 | Incorrect block size or logical | 
| | record size specified | 
| | | 
| 8A | Line size greater than | 
j | implementation-defined maximum | 
eed cS a a a J 


Error Codes Indicating Causes 
of Failure in Open Process 


Figure 7. 


OPEN/CLOSE FUNCTIONS 


The opening of a file occurs either 
explicitly by the use of an OPEN statement, 
or implicitly because of other I/0 
Operation statements. 


Opening a file involves the creation, 
within dynamic storage (subpool 1 of the 
Opening task), of an FCB, the setting of a 
file register to address the FCB, and the 
invocation of the data management OPEN 
executor. The closing of a file involves 
invocation of the data management CLOSE 
executor, freeing FCB storage, and clearing 
the associated file register. 


EXPLICIT OPENING 


In order to conserve storage, the module 
structure of the OPEN and CLOSE processors 
involves a ‘bootstrap' routine, IHEOCL, 
which links to the modules IHEOPN and 
IHECLT. In a multitasking environment 
IHEOCT links to IHEOPN and IHECTT. The 


bootstrap module passes to the loaded 
modules the address of a list of all 
necessary address constants and 
pseudo-register offsets, since these 
cannot be set in a module not 
link-edited with the executing 
program. The list is found in the 
library module IHESAP 
(non-multitasking) or IHETSA 
(multitasking). 


All errors are communicated back to 
IHEOCL/IHEOCT by means of the file 
registers; IHEOCL/IHEOCT then invokes the 
error handling subroutine. The error 
conditions are signaled in the high-order 
byte of the file register; IHEOCL/IHEOCT, 
upon detecting an error condition, sets bit 
0 of this register to indicate an 
unopenable file. The error codes are shown 
in Figure 7. 


Open Control Block (OCB) 


One of the parameters which may be passed 
to IHEOPN is the open control block (OCB), 
which is generated by the compiler. This 
four-byte control block indicates the 
attributes specified in the OPEN statement. 
During the opening process, this 
information is merged with that in the 
DCLCB in order to construct the proper FCB 
and check for attribute conflicts. (See 
Appendix I for details of the OCB.) 


The Open Process 


The flow through the OPEN modules is 
illustrated in Figure 8. 


The open process is performed by the 
modules IHEOPN, IHEOPO, IHEOPP, IHEOPQ and 
IHEOPZ which reside within the LINKLIB data 
set. These modules are dynamically loaded 
in order to conserve object-program 
storage. They initially receive control 
from a bootstrap module, IHEOCL 
(non-multitasking) or IHEOCT 
(multitasking); each module, after 
performing its functions for all files 
being opened, passes control to the next by 
the XCTL macro. 
bootstrap module. 


Open Process, Phase I: IHEOPN: This 
performs file attribute checking and 
Gefaulting functions. If a file being 
opened is REGIONAL, and is opened for 
DIRECT OUTPUT (creation), the module IHEOPZ 
is invoked by IHEOPN to initialize (format) 
the initial space allocation of the 
associated data set. Such initialization 


IHEOPQ then returns to the 


is required in order to allow subsequent 
direct insertion of records into the data 
set. If, in phase I, all files specified 
in the OPEN statement have detected errors, 
a return to the bootstrap IHEOCL is made 
immediately. Otherwise phases II, III and 
IV are invoked and a return is made to 
IHEOCL from IHEOPOQ. 
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Figure 8. Flow through the OPEN Modules 
Initialization for REGIONAL data sets of 
F format records involves writing dummy 
records (and keys, except for REGIONAL (1)) 
throughout the data set. On the other 
hand, initialization for U or V format 
records (REGIONAL (3) only) requires merely 
that the capacity record (RO) be written in 
each track to signal a free track, the 
track being automatically cleared as well. 


Open Process, Phase II: IHEOPO: This 
obtains storage for an FCB for each file 


being opened, and sets fields in both the 
DCB and the DCB-appendage according to the 
declared attributes. 


Open Process, Phase III: IHEOPP: This 
executes the OPEN macro, and accepts 
DCB-exits. 


Open Process, Phase IV: IHEOPQ: This 


dynamically loads record-oriented I/0 
modules (setting their addresses in the 
FCB), and enters the files being opened 
into the IHEQFOP chain of files opened in 
the current task. 
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The Close Process 


This process consists of: removing files 
from the IHEQFOP chain; freeing dynamically 
acquired storage (file control blocks, 
buffers, exclusive control blocks, and I/0 
control blocks); and deleting any 
appropriate dynamically-loadec 
record-oriented I/O modules. In the 
following description the non-multitasking 
module is followed with its multitasking 
alternative in parentheses. 


Module IHEOCL (IHEOCT) starts the close 
process; for an explicit close it links to 
IHECLTA (IHECTTA); for an implicit close to 
IHECLTB (IHECTTB). If the last operation 
On a BUFFERED SEQUENTIAL INDEXED OUTPUT 
embedded-key file, before it is closed 
explicitly, is LOCATE, module IHEOCL 
(IHEOCT) replaces the embedded key with the 
KEYFROM option, before passing control to 
IHECLT (IHECTT). For further information 
refer to Indexed Data Sets on page 35. 


Module IHEOCL (IHEOCT) calls IHEITC to 
finish formatting the current extent when 
closing a REGIONAL SEQUENTIAL OUTPUT file. 
If IHEITC finds a key sequence error due to 
a previous LOCATE statement on a REGIONAL 
file with U- or V-format records the key 
sequence is ignored and a message is 
displayed on the console. 


The normal return from a KEY on-unit is 
to the statement following that in which 
the condition is raised. Consequently, if 
the KEY condition is raised during the 
execution of an explicit CLOSE statement, 
the file will not be closed unless the 
Oon-unit also includes a CLOSE statement. 


In addition, if a file is closed 
implicitly (on termination of a task), 
IHEOCL or IHEOCT scans the IHEQFOP chain to 
find the file. In a multitasking 
environment, if a task is terminated 
normally, IHEOCT unlocks all records locked 
in the task and frees the corresponding 
exclusive blocks; if a task is terminated 
abnormally, it merely removes the exclusive 
blocks from their chains. For an implicit 
close, all events associated with event 
variables in the IHEQEVT chain are purged, 
and the associated IOCBs, if any, are 
freed. 


Modules IHECLT and IHECTT reside within 
the LINKLIB data set and are loaded 
dynamically in the same manner as the OPEN 
modules. They perform additional special 
functions as follows: 


Stream-oriented I/0: 
If OUTPUT with U-format records, the 


last record is written. 
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Record-oriented I/0: 


All incomplete event variables 
associated with the file are set 
complete, abnormal, and inactive, and 
the I/O operations are purged. 


In a multitasking environment: 


1. The event variables in the TEVT 
chain are set complete, abnormal, 
and inactive. 


2. For a REGIONAL EXCLUSIVE file, or 
an INDEXED EXCLUSIVE file with 
unblocked records, locked records 
are unlocked and all exclusive 
blocks in the TXLV chain are freed. 


3. For an INDEXED EXCLUSIVE file with 
blocked records, the file is 
unlocked. 


IMPLICIT OPENING 


If a file is not open and an I/O operation 
is initiated, then one of the compiler- 
interface modules (IHEIOA, IHEIOB (or 
IHEIBT), Or IHEION (or IHEINT)) calls 
IHEOCL (or IHEOCT), at implicit-open entry 
point IHEOCLC (or IHEOCTC), passing any 
implied parameters, and the open proces 
begins. : 


If the OPEN modules return control to 
IHEOCL (or IHEOCT) and the file is still 
unopened, the UNDEFINEDFILE condition is 
raised. 


STREAM-ORIENTED I/0 


Although I/O devices available within IBM 
System/360 are usually designed to transmit 
data in records of various lengths 
(blocks), the stream-oriented facilities 
allow a program to ignore record 
boundaries. The GET and PUT statements 
transmit data between storage and one or 
more record areas which exist within a 
buffer, the location within the buffer 
being updated as each data field is 
accessed. When a record area becomes 
filled (if output) or empty (if input), 
another record is obtained. Support for 
record access is provided by the data 
management access method QSAM (queued 
sequential access method). Normally, the 
GET and PUT data management macros are used 
in the locate mode, to conserve space and 
time; paper tape input, however, must use 
the MOVE mode. See Figure 9 for the flow 
through the stream-oriented I/O modules. 
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CURRENT FILE 


The current file is that one which is being 
operated upon by an I/O statement; it is 
established when an operation begins, and 
removed when the operation is completed. 
The current file is addressed through the 
pseudo-register IHEQCFL, which addresses 
the DCLCB for the file. This 
pseudo-register is available for inspection 
upon entry to ON blocks, and during 


transmission. Its format is shown in 
Figure 10. 
0 7 8 31 
Se a ek ee ; 
| 0 { A (DCLCB) | 
}--------}--------------------------------| 
| [ A(Abnormal return) | 
O22 ee eee eee ee eee 
Figure 10. Format of the Current File 
Pseudo-Register 


Within a stream-oriented data 
specification there may exist expressions 
which involve function references. In 
turn, the function procedure may itself 
perform I/O operations or may refer to ON 
blocks that perform I/O operations. When 
this situation occurs, it is necessary to 
stack the current file pseudo-register. 
The presence of the COPY option in a GET 
statement and the raising of the TRANSMIT 
condition for an item in the data stream 
are flagged in the fifth byte of IHEQCFL: 


TRANSMIT to be raised on item: Bit 5 =1 
COPY option in statement: Bit 6 =1 
Current file in PRV: Bit 7 = 0 
Current file stacked in DSA: Bit 7 =1 


Stacking of the current file is effected 
by the I/O initialization modules; upon 
entering such a module (e.g., IHEIOA and 
IHEIOB), the contents of the 
pseudo-register IHEQCFL are stored in the 
DSA (dynamic storage area) of the invoking 
procedure, as addressed by register DR. 
The stacking cell is termed the current 
file pseudo-register update. (See Chapter 
4.) Upon termination of an I/O operation, 
either normally, or by means of a GO TO 
statement out of an ON block, this cell is 
copied back into the pseudo-register 
IHEQCFL. 


GET and PUT statements with the STRING 
option employ the current file 
pseudo-register, but no abnormal return 
entry exists. Instead, the latter four 
bytes address a simulated FCB. 
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STANDARD FILES 


The standard files, SYSIN and SYSPRINT, 
have default titles equivalent to their 
file names. The compilation of GET and PUT 
statements without explicit FILE options 
causes compile-time syntax substitution of 
the file names SYSIN and SYSPRINT 
respectively. These files have the same 
compiled linkage to the library as other 
files. Within the library, SYSIN is not 
used; the file SYSPRINT, however, is used 
in that error messages and listing of data 
fields for the COPY and CHECK options 
require the presence of this file. 


SYSPRINT may be implicitly opened either 
by: 


1. the First PUT executed in the compiled 
procedure, or 


2. acall from within the library for the 
COPY option or an error message. 


If the library attempts to open this file, 
and it cannot be opened (missing DD card, 
etc.), this situation is flagged and all 
error messages will appear on the system 
console. In addition, any COPY options, or 
system action for the CHECK condition, will 
be ignored. The UNDEFINEDFILE condition is 
suppressed in the above cases. 


If a compiled procedure attempts to open 
SYSPRINT, and it cannot be opened, the 
normal UNDEFINEDFILE condition is raised. 


Because the library and the source 
program both use the SYSPRINT file, it is 
necessary that they both refer to the same 
DCLCB. This is achieved by the use of 
CSECT facilities within the linkage editor; 
both the compiled DCLCB and the 
library-supplied DCLCB for SYSPRINT (within 
the module IHEPRT) are supplied with the 
same name, so that only one of them will be 
placed within the linked program. The name 
Of both CSECTs is IHESPRT; the name of the 
associated file register is IHEQSPR. 


SYSPRINT IN MULTITASKING 


In a multitasking environment, to ensure 
that there is no conflict between 
operations in different tasks that refer to 
the same non-exclusive file, it is 
necessary for the programmer to synchronize 
these operations (by uSing an EVENT 
variable, the COMPLSTION pseudo-variable, 
and the WAIT statement). Since the library 
uses the file SYSPRINT, it is not possible 
for the programmer to synchronize all 
operations on this file. Therefore the 


library module that implements PUT 
statements for SYSPRINT (IHEIOB), and other 
modules that use this file, issue an ENQ 
macro instruction before executing each PUT 
statement on SYSPRINT, and a DEQ macro 
instruction on completion of the operation. 
All SYSPRINT operations cannot be enqueued 
on the same resource, since this could 
result in an interlock situation (two or 
more operations, each waiting for the 
completion of the others). For example, 
this would be the case if a PUT statement 
involved a function reference that required 
another PUT operation; if both were 
enqueued on the same resource, the second 
operation could not commence until the 
completion of the first, which itself could 
not proceed until the function had returned 
an answer. 


The library resolves the difficulty by 
employing a resource counter (the first 
byte of the current-file field in the DSA: 
see Appendix J). Before each SYSPRINT 
operation is executed, the operation is 
enqueued on the resource number in the 
counter, and the counter is then 
incremented by one; on completion of the 
operation, the counter is decremented by 
one before the operation is dequeued. When 
a new DSA is obtained (on entry to a new 
block: see Chapter 4), the resource count 
is copied from the DSA of the block from 
which the new block was entered. 


In the example (Figure 11), when the. 
major task (task A) is initialized, the 
resource count in its DSA is set to zero. 
Task A then attaches tasks B and C, and in 
each case the resource count (0) is copied 
into the new DSA. Tasks A, B, and C then 
réquest PUT operations, all of which are 
engueued on resource 0; in each case the 
resource count is then incremented by 1. 
These operations are therefore completed in 
the order in which they were requested. 


During execution of the PUT statement in 
task B, an error condition occurs that 
involves a library call to print a message 
(e.g., UNDERFLOW). The library PUT 
statement is enqueued on resource 1, since 
the resource counter is incremented after 
the task PUT statement is enqueued, but 
before the statement is executed. The 
library PUT operation is therefore not 
dependent on the completion of the PUT 
statement that raised the error condition. 


If a GO TO statement is executed that 
passes control to a statement preceding a 
series of enqueued operations, the program 
management routine IHETSAG releases the 
DSAs of the blocks thus freed and dequeues 
the I/O operations they contain. This is 
illustrated in task C (Figure 11), where 
control is passed to an on-unit as a result 


of an error in a PUT statement in a 
function reference made during the 
execution of the second PUT statement in 
the task. The PUT statement is enqueued on 
resource 0, and the resource count is then 
incremented. When the function is called, 
the resource count (1) is copied into its 
DSA; consequently, the next PUT statement 
is enqueued on resource 1, and the counter 
is again incremented. The count 2 is 
copied into the on-unit DSA when control 
passes to the on-unit. On execution of the 
GO TO statement, which passes control back 
to a statement preceding the original PUT 
statement, IHETSAG frees the function and 
on-unit DSAs, dequeues all the PUT 
operations, and resets the resource counter 
in the DSA for task C to its value on entry 
to the task (0). 


No special provision is made for 
handling SYSPRINT resources on termination 
of a task, since this file cannot be used 
by the library end-of-task exit routine. 


The qname and rname used in the ENQ and 
DEQ macro instructions are: 


qname (two words): 
Bytes 1-4: A(SYSPRINT FCB) 
Bytes 5-8: A(SYSPRINT FCB) 


rname (1 byte): 
Resource count in DSA 


GET/PUT OBJECT PROGRAM STRUCTURE 


The code compiled for stream-oriented I/0 
GET and PUT statements has the general 
Structure illustrated in Figure 12. There 
are three ‘call sets" compiled for these 
statements: 


1. Initialization: 


This call invokes one of the I/0 
initiator modules, passing: 


ae The address of the file DCLCB. 


b. The address of the termination 
call. (This is the abnormal 
return which is set within the 
current file pseudo-register 
IHEQCFL. ) 


c. The address of the LINE or SKIP 
value. 


The initialization process includes 
stacking the current file, checking 
the specified file (and opening it if 
not already open), and performing any 
necessary option operations. 
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Task C 


Task B Task A 
(major task) 
| 
0 | 
| 
(Aes SS Se Sen aS re { 
Oo | | 
}------------------------, 
| | oO. (| 
ENQ | 
1 Error | | 
PUT-~—-------- 7 | | 
0 | | ENQ 
DEQ | ENQ 1 
i 1 PUT 
| a Message PUT 0 
i routine 0 DEQ 
| 1 | DEC 
| | |  inense eines ones. > | 
| | | | 
| | | 
ENQ | | | 
2 | ENQ 
PUT | 1 Function reference 
1 | PUT--—------- 1 
DEQ | | | 
| | | | 
| [ | 1 PROC; 
| | | 
| | | | 
| | | 
| | ENQ 
| | 2 Error 
Note: The figures at | | PUT-------- 1 
the left of each column | | | 
indicate the contents of | | | | 
the resource counters. | | | On-unit 
| | | 
{ | | 2 BEGIN; 
| | | | 
| | | | 
| | | 
| | | | 
| | | | 
L---.—--.-—-— DEQ<------- DEQ<--~-- GO TO 
| 
| 
| 
Figure 11. Allocation of SYSPRINT Resources in Multitasking 
2. Data specification: 3. Termination: 
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This is a series of calls to perform 
list-, data-, or edit-directed 
stream-oriented I/O operations. This 
series is omitted only for GET/PUT 
statements which have no data 
specification. Details of the 
implementation of the three forms of 
data specification appear in ‘Data 
Specifications‘, below. 


This call invokes the terminal 
subroutine of the module which 
performed the initialization. At this 
point the current file is unstacked 
and (for PUT calls) V format output 
records have their record-length field 
updated. 


eee ea ee ee eee 


i 
| Initialization | 
| call i 


| 

V 
—a- a+ 7 
Data | 
Specification | 
call, | 


| 
Vv 


Call set 1 


{ 
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Call set 2 
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| Data { 
| Specification | 
{ calln | 
sdaela sepsis -y------—4 


<b ae cee ee cee oe ee eee 


! 
! 
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Call set 3 | Termination 


| call 


Coes ee eet ORS ee Se ee a a ee Se 


bee comes camwes ommes conf 


Object Program Structure of 
GET/ PUT 


Figure 12. 


DATA SPECIFICATIONS 


There are three forms of data 
specification: 


Data-directed 
List-directed 
Edit-directed 


Compilation of any data specification 
yields a series of one or more calls to the 
library for transmission of data between | 
program storage and a record buffer. For | 
list- and data-directed I/O, the data items 
transmitted are passed by means of the 
standard linkage described above. (See 
"Linkage Conventions’ in Chapter 2.) The 
PL/I standard (using registers) is employed 
wherever possible; where it is not, the : 
operating system standard (using a 
parameter list) is employed. For 
edit-directed I/O, the ‘executable format 
scheme‘ described below is required. 


The ON CHECK facilities for data items 
being input are supported by compiled code 
between data-list item specifications, in | 


the instances of list- and edit-directed 
I/O; data-directed I/O determines the 
existence of this condition from the symbol 
table entry for a given data item. 


EXECUTABLE FORMAT SCHEME 


The executable format scheme exists to 
support two requirements for edit-directed 
data items: 


1. The matching at object time of 
data-list items with format-list 
items. 


2. The evaluation of expressions during 
an I/O operation. 


The scheme exists in compiled code for use 
by the library format directors and 
conversion package. (See ‘I/O Editing and 
Data Conversion’ in Chapter 8.) 


The scheme is required because 
edit-directed data specifications contain 
format lists composed of format items that 
may have expressions for replication 
factors and format subfields. These 
expressions may have to be evaluated with 
values read in during a GET operation. 
Finally, the use of dynamic replication 
factors and the possible existence of array 
data-list items of variable bounds prevent 
any pre-determinable matching of data-list 
items and format-list items. 


Basically, the scheme calls for the 
existence of two location counters, one for 
a compiled series of data-list item 
requests, the other for a compiled series 
of format-list item specifications. These 
two series are compiled as the secondary 
calling set for a GET or a PUT operation. 


TO support the dynamic matching of a 
format-list item with any data-list item, a 
group of format directors exists within the 
library; one of these directors receives 
the call from the secondary compiled series 
of format item specifications. A director 
will determine which conversions are 
required to satisfy the transmission of a 
data item according to its internal 
representation (described by its DED) and 
its specified external representation 
(described by a FED). 


The structure of edit-directed compiled 
code is illustrated in Figure 13. The 
first column, 'Primary code‘, consists of 
calls to units in the second column, 
"Secondary code’; i.e., data-list items are 
requesting a match with a format-list item. 
The third column shows the flow within the 
library as set up by format directors. 
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The scheme works as follows: 


1. The address of the start of the 
format-list code (executable format) 
is obtained. 


2. Transmission of the first data item is 
requested; its storage address and DED 
address are loaded into registers RA 
and RB. 


3. Control is transferred to the 
executable format; at the same time 
the location counter of the data-lList 
code is updated. 


4. The executable format loads, into 
register RC, the address of an FED. 


5. A call is made to a format director 
and at the same time the location 
counter of the format-list code is 
updated. 


Primary Code Secondary Code 


6. The format director causes the 
conversion package to convert the data 
according to DED and FED information, 
storing the converted data in the 
Specified storage address, if input, 
Or placing it in a buffer, if output. 


7. Return is then made to the data-list 
code, by means of the data-list 
location counter, LR. 


8. The above steps, 2 through 7, 
repeated until the end of the 
data-list code is reached. 


are 


Within both primary and secondary code, 
looping and invocation of function 
procedures may occur. Within secondary 
code, the appearance of control format 
items (PAGE, SKIP, LINE, COLUMN, X) will 
cause the location counter for primary 
code, register LR, to be temporarily 
altered, so that control is returned from 
the library, not to the primary code, but 
to the secondary code. This allows the 


Format Directors 


ee SS OS. ED PES a EE Ce EE ag 


Initialization 
| i 
| 
V 
mea, eS. ae tee ee s 
{| Request -}---->| Specify }+---->| Format | 
{data item 1| | format | | director |<---------- 4 
jtransmission| ,--->| 1 --———> | | | 
5 | Ll. —-— -——.—.— — —— J L_--,~7-----4 V 
| (1) (3) (mono - 7 
(rt rr rn rrr rrr 4 | Conversion | 
| | | | package | 
| | pS aSs= | | 
V | L--—-—-—~--~~ J 
GSH aa 7 GS re aa ae ca 1 A 
| Request 1 | | Specify | | | Format | | 
{data item 2}----—>| format b---->| director |<---------- : 
|transmission| | | 2 i | | | 
eis cetencn eee | | a re eee | L a ean ee am T os ee ee ee dj 
| | (2) | 
| | | 
| | \ 
(ro nn = 
| | | 
V | 
—S- 1 | | 
| Request | | | 
jdata item 3}-4 | 
| transmission | | 
Ucaicel actos ones eacametes 4 | 
| 
| | 
| 
Vv 
Termination 
Figure 13. Executable Format Scheme 
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data-list item which activated the control 
format item to be matched with a data 
format item. 


OPTIONS 


COPY: This option causes each data field 
accessed during a GET operation to be 
listed on the standard output file, 
SYSPRINT. This is performed by calling 
the module IHEPRT. Each data field 
occupies the initial portion of a line. 
If there is no DD card for SYSPRINT, 
the COPY is ignored by IHEPRT. 


STRING: This option causes a character 
string to be used instead of a record 
from a file. This situation is made 
transparent to the normal operation of 
the I/O modules since the 
initialization module for GET/PUT 
STRING (IHEIOC) constructs a temporary 
FCB for the string. Information 
regarding the address and length of the 
string is set in the FCB fields TCBA, 
TREM and TMAX. A temporary file 
register is created in the second word 
of the pseudo-register IHEQCFL. (A 
dummy DCLCB is placed in front of the 
generated FCB and consists of two bytes 
which indicate the offset of the dummy 
file register.) 


PAGE, SKIP, LINE (print files): These 
options cause the current record (which 
is equivalent to a ‘line') to be put 
out, and a new record area to be 
oktained. SKIP can also be used with 
input to cause the rest of a record in 
the input stream to be ignored. Record 
handling for these functions is 
performed by the module IHEIOP. All 
printing options (and format items) are 
supported by use of the ASA control 


characters: 

1 Page eject 

+ Suppress space before printing 
b Single space before printing 

Q Double space before printing 


Triple space before printing 


Should spacing greater than triple be 
required for a LINE or SKIP request, a 
series of blank triple space records is 
generated, followed by a single or 
double space record, if necessary. 


SKIP (non-print files): 


1. Input files: The SKIP(n) option 
causes the rest of the current 
line (record) to be ignored in the 
input stream, and a further 
(n - 1) lines to be ignored. 


2. Output files: The SKIP(n) option 
causes the remainder of the 
current line (record) to be 
ignored and (n - 1) blank lines to 
be inserted into the output 
stream. Note that, for format F 
records, each line is padded with 
blanks; for format V and U 
records, only the necessary 
control bytes and record lengths 
are supplied. 


RECORD-ORIENTED I/0 





OBJECT PROGRAM STRUCTURE 


In record-oriented I/O, the data entities 
accessible to the source program are data 
Management logical records (unlike 
stream-oriented I/O, where the data 
entities are data fields). 


A wider range of record access is 
therefore available with record-oriented 
I/O: records may be keyed or not, may be 
directly or sequentially accessed, and may 
be manipulated within the data set by 
insertion, replacement, or deletion. The 
specific facilities available vary 
according to the data management access 
method employed to support a given data 
set. 


The data management facilities employed 
are indicated in Figure 14, according to 
the organization of the data set. Note 
that not only the declared organization but 
also the mode of access and the format of 
records determine the chosen access method. 
Details of the manner in which the access 
methods are employed are provided in 
"Access Method Interfaces‘. 


General Logic and Flow 


The overall flow of record-oriented I/0 
modules is illustrated. in Figure 15. 
Modules IHEION(IHEIOG) (non-multitasking) 
or IHEINT(IHEIGT) (multitasking) are 
general interface modules, one of which is 
invoked by a compiled call for any 
record-oriented I/O statement, in either a 
non-multitasking or multitasking 
environment. This module interprets the 
requested I/O operation, verifies its 
applicability to the specified file (and, 
possibly, implicitly opens it), and then 
invokes an access method interface module 
(characterized by the module names IHEIT*) 
to have the operation performed. 
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a ma a a a a aR Ra aa lca a am a a me a ma ar | 


| | | | | Record |Access|{ Notes on Use of | 
| Organization | Access | Mode |Buffering |Format |Method| Access Method | 
}---------—---}------------} ------ }----------}--------------}------}}-------------------- 
| | i |BUFFERED |ALL {|QSAM_ | Locate-mode | 
| | | INPUT | | | | (except paper tape) | 

| CONSECUTIVE | SEQUENTIAL | OUTPUT }---------- f-------------- $------ }----------------~~-- 
| | UPDATE|UNBUFFERED|F, U, V [BSAM | - 
}------------- }------------ $o----~}---------- }-------------- }--—-- }-------------------- { 
| | {INPUT |BUFFERED | | | Scan-mode; | 
| | |UPDATE| or {\F, FB2 { | ESETL/SETL | 
| | SEQUENTIAL }------ j UNBUFFERED | {QISAM }------------—-------- 4 
| INDEXED | | OUTPUT | | | | Load-mode | 
}------------ }------}---------- }-------------- }------}-------------------- { 
| | DIRECT | INPUT | - [F, FB {BISAM | ~ | 
| | | UPDATE | | ] | 
}-------------}-~-----------}~-----}----------}--------------}------}--------------------4 
| | J INPUT |BUFFERED |F {|QSAM/ | = | 
| | SEQUENTIAL |UPDATE| or | (REGIONAL(1),|BSAM? | | 
| | }------ {UNBUFFERED| REGIONAL(2)) }------ $~-----~+~------~-+~---~- ] 
| _ | OUTPUT | | {[BSAM |BSAM Load-mode | 
| }------------ }------ }---------- { }------}-------------------- { 
| | | | |F, U, V | | REGIONAL (1) 2 | 
| | i | - | | {Relative record | 
| REGIONAL(1) | | | { {|BDAM |without keys | 
{| REGIONAL(2) | JINPUT | | (REGIONAL(3)) | | REGIONAL ( 2) 2 
| REGIONAL(3) { DIRECT | OUTPUT | | | {Relative record 
| | | UPDATE | | { jwith keys | 
| | | { | | REGIONAL (3) 2 | 
| | | | | | |Relative track | 
| | | | | [with keys | 
}------------- }------------ }------4---------- }-------------- +------ }-------------------- { 
|TELEPROCESSING TRANSIENT |INPUT |BUFFERED |G,R [QTAM | - | 
| | | OUTPUT | 
iia eee 1_—---+---~---1-- ----4----+---+- 4------- -- - ---b-b +--+ J 
| 


+ 
{Note 1: FB is not allowed for UNBUFFERED files 
{Note 2: OUTPUT causes data set to be formatted using BSAM (BDAM load-mode) at open time| 
|Note 3: QSAM is used for REGIONAL(1) BUFFERED but not KEYED | 
ee SN ea ne Cm ce peda pry Ase -p  D e pmr e Pa orn eae ev SB vere pan OR RL ee Oey aya moe Eee J 


Figure 14. Data Management Access Methods for Record-Oriented I/0 


Modules IHEION and IHEINT supersede analysis and record-variable length 
modules IHEIOG and IHEIGT at Release 17. checking, and establishes any control 
The latter are retained in case a blocks required. It then invokes data 
previously compiled load module is management for the transmission of a 
link-edited with the new library. The new record. After transmission, or (if the 
modules perform the same function as the EVENT option is employed) after initiation 
old except that they transfer control to of transmission, control returns to the 
the transmitters rather than link to them. general interface module IHEION (or 
The transmitters return direct to compiled §IHEINT), and thence to the compiled 
code. This avoids saving and restoring program. Errors may be detected within 
registers between the interface module and IHEION (or IHEINT) before an interface 
the transmitter. module is invoked, or within an interface 

module either before or after data 

The verification of a statement is Management has been invoked. The relevant 

performed by IHEION (IHEINT in ON condition is raised when detected. 


multitasking) by ANDing together a mask at 
offset -8 from the FCB and the second word 


of the Request Control Block. If the As indicated by the overall flow 
result is zero then the statement is diagram, record-oriented I/O is implemented 
invalid. The mask in the FCB is set up by in such a fashion that the addition of 
IHEOPQ to indicate which statements are further access method interface modules 
valid, and the RCB contains the statement requires minimal changes (if any) within 
type as a single bit in its second word. other parts of the implementation. The 
general interface module IHEION or IHEINT 
On receiving control, the interface provides each access method interface 
module first performs any necessary key module with a standard parameter set: 
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Note: An asterisk indicates that 
the module can be entered 
directly from compiled code 


V 
eS Ee == 5 aces 
JOCL/OCT *[ »------------- 4{—--—-~~ 7 
}--------- 1 | V Vi OY¥V 
| ‘ae Secs. == 
| CLOSE/ }---------- 1] ITB | | ITc Jf | 
. (OPEN. “pes==-9s=—9 ))[-=---- PJ s==> 
| ices vif { BSAM [| | BSAM | | 
| Pid | | (LOAD)| | 
Lo. ~-=——) ||| t------ i ie eee eee + | 
| | \----------, L 
t.——...-------, | L-------.-~- ee 
Ghee areal Canes | 
V | | 
--------- -y 0 peeen n= | | 
| opz | [| OPN | | | 
Seceenieos, “pose seeeee V l 
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| | | | 
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| OPEN --->| OPEN $}-->| OPEN --—4 
| Phase II | | Phase IIT] | Phase IV| 
eee eae ee ee _4 alee ere J Sena Reser eer | 


e Figure 15. Linkage of Access Modules in 


RA: A(Compiled parameter list) 


Parameter list: 
A (DCLCB) 
A(Record dope vector/IGNORE/SDV) 
A(Event variable)/0/A(Error return) 
A (KEY | KEYFROM| KEYTO SDV) /0 


A(Request control block) 


7 
{ Compiled [}-~------------ = 


| Code [ | 
bene ane and Vv 
| (SSS sere 7 
V | OSW/TSW *| 
{ION(IOG)/INT(IGT) *| | WAIT | 
}-------~----------- | | 
| Compiler L--_-_ y---~ 
| interface | | 
ievouoces r--------- J 
| | 
| <----~--~-~----~-------- J 
| 
| 
sass hee te 4 
| 
| 
Pea ee er eee {oe asss=—=-= 1 a a a 1 
| | | | | 
V V V V 
rasta 1. ft a 
ITE | | ITH |f] ITF Jj {| «IT | 
~--------{ }--------- {| f---------4 }--------- 
BISAM | | BISAM {|| BDAM | [| BDAM | 
No Multi-] | Multi- |||]No Multi-| | Multi- | 
tasking | | tasking |||tasking | | tasking | 
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VV V V V | 
f--=-=-=- 1 p= === -= 7 presa—a=7. geese | 
{| ITD | | «ITD | | «ITG | | <ITK || 
p-------4 f-------{ f------- ---~---| 
| QSAM_ | {| QISAM | {| QSAM | | QSAM || 
| SPANNED | | | | NON- } {SPANNED | | 
| OUTPUT| | | | SPANNED] | INPUT || 
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Record-Oriented I/0 


The record dope vector and the request 
control block are described below under 
*Record-Oriented I/O Control Blocks’. 


The interface modules are also invoked 
to handle WAIT statements associated with 
I/O events. The WAIT module, having 
determined that an event variable (see 
Appendix I) is associated with a 
record-oriented I/O operation, invokes the 
relevant I/O transmitter (IHEIT*), passing 
the following parameters: 
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RA: A(Compiled parameter list) 
Parameter list: 
A (DCLCB) 
A(IOCB being waited for) 
A(Event variable) 
(Reserved) 
A(Request control block) 


The transmitter then completes the 
previously initialized record transmission, 
and performs any checking required before 
returning control to the WAIT module. (See 
also ‘The WAIT Statement’ in ‘PL/I Object 
Program Management in Multitasking‘ .) 


From the arguments, the interface module 
is able to determine fully the operation 
requested of it. The location of the 
required interface module is available to 
IHEION from the FCB associated with the 
file; the field TACM in the FCB is set 
during the open process to point to the 
appropriate dynamically loaded module. 


Thus, when extra interface modules are 
provided, the only change required in the 
open modules is the provision of code to 
set TACM and any other FCB fields relevant 
to the new access method interface. 


RECORD-ORIENTED I/0 CONTROL BLOCKS 


Record Dope Vector (RDV) 


The record dope vector is an eight-byte 
block that describes the record variable. 
Its format depends on the type of statement 
and the associated options: 
Bytes 0-3: ACINTO/FROM area), or 
A(POINTER variable) for SET 
option in READ statement, 


or 
A(buffer) for LOCATE 
statement 
Byte 4: Reserved 
Bytes 5-7: Length of variable 


String Dope Vector (SDV) 


The address of the string dope vector is 
passed instead of that of the record dope 
vector to record I/O interface modules when 
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the input or output of varying strings is 
requested. The string dope vector is an 
eight-byte block: 


Bytes 0-3: A(CINTO/FROM string) 
Bytes 4-5: Maximum length of string 
Bytes 6-7: Current length of string 


(output), undefined 
(input) 


Request Control Block 


This eight~-byte block contains the request 
codes, in the first four bytes, for various 
RECORD I/O operations and options. The 
format is defined in the BREQ field of the 
I/O control block (IOCB). (See Appendix 
I.) 


The additional four bytes which are 
contained in the compiler argument list are 
not copied into the IOCB. Each type of 
Record-oriented I/O statement is 
represented by one bit as follows: 


0 READ SET 

1 READ SET KEYTO 

2 READ SET KEY 

3 READ INTO 

4 READ INTO KEYTO 

5 READ INTO KEY 

6 READ INTO KEY NOLOCK 

7 READ IGNORE 

8 READ INTO EVENT 

9 READ INTO KEYTO EVENT 
10 READ INTO KEY EVENT 

11 READ INTO KEY NOLOCK EVENT 
12 READ IGNORE EVENT 
13 WRITE FROM 

14 WRITE FROM KEYFROM 

15 WRITE FROM EVENT 

16 WRITE FROM KEYFROM EVENT 
17 REWRITE 

18 . REWRITE FROM 

19 REWRITE FROM KEY 

20 REWRITE FROM EVENT 

21 REWRITE FROM KEY EVENT 
22 LOCATE SET 

23 LOCATE SET KEYFROM 

24 DELETE 

25 DELETE KEY 

26 DELETE EVENT 

27 DELETE KEY EVENT 

28 UNLOCK KEY 

29-31 Reserved 


I/O Control Block (IOCB) 





Record-oriented I/O employs several data 
Management access methods that require that 
operation requests be provided with a 
special form of parameter list. This 
parameter list is termed the data event 

- control block (DECB). A DECB must be 
provided for each operation, but may be 
reused when the operation is completed. If 
several operations are outstanding (owing 
to the use of the EVENT option in I/0 
statements, or multitasking), then one DECB 
is required for each operation. 


In order to meet these requirements, the 
PL/I open process allocates one or more I/0 
control blocks (IOCB), which are 
subsequently manipulated or increased in 
number as follows: 


DIRECT access (BISAM and BDAM): 
The IOCBs are created by 
IHEITE(BISAM) or IHEITF(BDAM); for 
multitasking, they are created by 
IHEITH(BISAM) or IHEITJ(BDAM). 
Only one IOCB is created at open 
time; any others required are 
created when needed. 


SEQUENTIAL access (BSAM only): 
All the required IOCBs are obtained 
at open time; an attempt to use 
more than those already in 
existence raises the ERROR 
condition. 


The IOCB format for both these usages is 
described in Appendix I. 


A number of IOCB fields exist in order 
to support the EVENT option. Since the 
operation is split into two parts -- 
initiation through the READ, WRITE, etc., 
statements, and completion by the WAIT 
statement -~ information regarding a 
particular operation must be retained for 
use at the time of completion. For 
example, if a hidden buffer is employed for 
a READ, the address of the user's record 
variable must be retained for subsequent 
movement from the buffer to the specified 
area. 


IOCB -- SEQUENTIAL Usage: Manipulation of 
IOCBs for SEQUENTIAL usage is required only 
for BSAM, which is employed for: 


1. CONSECUTIVE UNBUFFERED files. 


2. SEQUENTIAL creation or access of 
REGIONAL files which have the KEYED 
attribute or are unbuffered. 


_ A number of IOCBs is allocated during the 
- Open process by means of the GETPOOL macro; 
subsequent selection of a particular IOCB 


is made by a routine similar to that 
provided by the GETBUF macro. Whenever an 
IOCB is selected, it is entered into the 
chain of IOCBs currently in use; the TLAB 
field in the FCB points to the last IOCB to 
be used. 


The chain of IOCBs is required for two 
reasons: 


1. All I/O operations must be checked in 
the order in which they were issued. 


2. Detection of dummy records for a 
REGIONAL (2) or (3) data set requires 
reordering of outstanding requests 
(due to the use of the EVENT option). 


This chain, however, is principally 
required for the EVENT option, which can 
cause more than one I/O operation to be 
outstanding at a given time. 


The number of IOCBs (buffers) allocated 
is determined by the DD statement 
Subparameter NCP. The value of this 
subparameter should not be greater than 1 
unless the EVENT option is employed; if 
NCP = 1, there is then one IOCB and one 
channel program. If NCP is unspecified a 
default of 1 is used. 


The size of each IOCB varies, depending 
upon the organization, the record format of 
the data set, and whether or not the file 
(if REGIONAL) has the KEYED attribute. 
Figure 66 in Appendix I specifies the size 
requirements. 


IOCB_--_DIRECT_ Usage: Manipulation of 
IOCBs for DIRECT usage is required for botn 
BDAM and BISAM. One IOCB is allocated toa 
DIRECT file when it is opened; subsequent 
selection of an IOCB is performed by the 
modules IHEITE, IHEITF, IHEITH, and IHEITJ. 
Unlike SEQUENTIAL access, the order of I/0 
Operation is not normally considered. 
(However, see the BISAM interface modules 
IHEITE and IHEITH.) 


The chain of IOCBs for a given file is 
anchored in the TLAB field in the FCB; the 
chain may be extended beyond the original 
Single IOCB if the EVENT option or 
multitasking is used. An extension occurs 
if, while there exists an I/O operation 
that has not been completed, another I/0 
operation is initiated. 


IocBs for DIRECT access are obtained in 
subpool zero, in order to cope with . 
multitask manipulation of the chain. The 
chain of one or more IOCBs is released when 
the file is closed. 
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Exclusive Block 


When a DIRECT UPDATE file is opened in a 
multitasking environment, the interface 
module IHEITH (BISAM) or IHEITJ (BDAM) is 
loaded instead of IHEITE or IHEITF. IHEITH 
and IHEITJ contain code to implement the 
EXCLUSIVE attribute. When a record is 
locked, an exclusive block is created in 
subpool 1 of the current task; the block is 
freed when the record is unlocked. The 
exclusive block contains the qname (address 
of the FCB for the file) and rname (region 
number for REGIONAL(1), region number and 
key for REGIONAL(2) and (3), and key for 
INDEXED) required by the ENO and DEQ macro 
instructions that are issued to lock and 
unlock the record. The format of the 
exclusive block is given in Appendix I. 


ACCESS METHOD INTERFACES 


This section describes how the PL/I Library 
relates to the various data management 
access methods for record-oriented I/O, and 
gives details of the support required from 
the library for various PL/I features. 

This information supplements, but does not 
replace, that provided in the module 
summaries and in the module listing 
prefaces. 


CONSECUTIVE Data Sets 


The access methods employed for this 
organization are QSAM and BSAM. The choice 
between them is governed by the file 
attributes BUFFERED and UNBUFFERED: 


BUFFERED: QSAM (All record formats) 
UNBUFFERED: BSAM (F,V,U) (Blocked 
records are illegal) 


OSAM (IHEITG): A BUFFERED file is 
specified in order to take advantage of 
automatic transmission, process-time 
overlap, and blocking or deblocking of 
records. All record formats may be 
handled. 


The locate mode of the GET and PUT 
macros is employed with this access method 
(except for paper tape devices) for the 
following purposes: 


1. To support the SET option in READ and 
LOCATE statements, and to support the 
REWRITE statement without the FROM 
option. Module IHEITG allocates the 
data management buffers for the 
records, and sets the pointer 
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appropriately. The first byte of a 
buffer is always on a doubleword 
boundary; for blocked records, the 
user must ensure that his alignment 
requirements are met by adjusting the 
lengths of the variables being 
transmitted. 


2. TO remove or add V-format control 
bytes if the INTO or FROM option is 
employed... 


Paper tape input requires the use of the 
move mode to effect translation of the 
characters transmitted. The open process 
establishes a work area, placing its 
address in TREC; the GET macro instruction 
specifies this area as the receiving area. 
If an illegal character is read from the 
paper tape, the access method (QSAM) passes 
control to the SYNAD routine in IHEITG; 
control returns from the SYNAD routine to 
QSAM. When the GET macro instruction has 
been satisfied, the data is moved into the 
record variable or a pointer is set, and 
the TRANSMIT condition is raised. 


Closing a data set being created by QSAM 
may cause output records to be written by 
the close executor. If an error occurs 
during the closing process, the operating 
system uses the ABEND macro to end the 
task. 


QSAM Spanned Records (IHEITK,IHEITL): 
Buffered VS- or VBS-format records are 
processed using QSAM Locate Mode for input 
(module IHEITK) and QSAM Data Mode for 
output (module IHEITL). 


The methods employed are similar to 
those described above for module IHEITG 
although the following should be noted: 


1. Update Mode (REWRITE) is not supported 
by the library, since it is not 
possible to update complete records 
(O/S restriction). 


2. The use of LOCATE or READ SET 
statements will cause a work area to 
be established equal to the maximum 
record size. This area is only 
released if there is a subsequent READ 
(without SET) or WRITE statement. 


BSAM (IHEITB): An UNBUFFERED file is 
specified in order to avoid the space and 
time overheads of intermediate buffers when 
transmitting records. Overlap of 
transmission and processing time is only 


available if the EVENT option is employed. 


BSAM requires the use of DECBs to 
communicate information regarding each I/0 
operation requested of it; see ‘I/O Control 
Block (IOCB)* and Appendix I (IOCB) for 
details of the DECB. IHEITB selects an 


IOCB (which contains a DECB area) from the 
IOCB (buffer) pool for each input/output 
operation. The IOCBs used for CONSECUTIVE 
organization do not contain hidden buffers, 
except when V-format records are employed. 
Hidden buffers are used in this case so 
that the V-format control bytes can be 
eliminated from the record before the data 
is moved into the record variable. If, 
however, the data set consists of F-format 
unblocked records, and the size of a record 
variable is less than the fixed size of 
data set records, a temporary buffer area 
is dynamically obtained. The use of a 
temporary buffer area for input prevents 
the destruction of data following the INTO 
area; for output, it prevents triggering of 
the fetch-protect interrupt. 


INDEXED Data Sets 


The access methods employed for this 
organization are QISAM and BISAM; they are 
used thus: 


QISAM: SEQUENTIAL creation and access 
BISAM: DIRECT access 


All usage of INDEXED data sets requires the 
presence of buffers, even though the file 
is UNBUFFERED or DIRECT. The buffer is 
required in order to deal with a 10-byte 
overflow record link-field. Only F- or 
V-format records, blocked or unblocked, are 
permitted. 


QISAM (IHEITD/IHEITN): SEQUENTIAL creation 
and access of INDEXED data sets is 
performed using this access method. 
Creation requires that keys be presented in 
ascending collating sequence. The sequence 
is checked by the library before the PUT 
macro is executed, in order to synchronize 
a given WRITE statement with the raising of 
the duplicate KEY condition. This 
arrangement is necessary because, since PUT 
LOCATE is employed, QISAM would normally 
raise the condition only on the subsequent 
PUT operation. 


For records with embedded keys, when a 
WRITE statement with a KEYFROM string 
shorter than the key length, or a LOCATE 
statement, is executed, the KEYFROM string 
is placed in an area addressed by TPKA in 
the FCB. In the next operation on the file 
after a LOCATE statement (including a CLOSE 
statement), the KEYFROM string is compared 
with the key embedded in the data in the 
buffer. If they are unequal, the KEY 
condition is raised. On normal return from 
the on-unit, control passes to the next 
statement in the program (i.e., the one 
following that which caused the KEY 
condition to be raised). The process of 


comparing keys and raising the KEY 
condition is repeated in successive 
statements that refer to the file until the 
embedded key has been changed. (After a 
LOCATE statement has been executed, no 
further operations are possible on the file 
until the record has been transmitted; for 
records with embedded keys, this cannot 
occur until the KEYFROM string matches the 
embedded key.) 


When a file is closed implicitly (i.e., 
on termination of a task), the KEYFROM 
string overwrites the key part of the 
record in the buffer, and the record is 
written onto the data set. If the KEYFROM 
string is not identical with the embedded 
key, a message is printed out at the 
console. 


To support the REWRITE statement without 
the FROM option, the key is saved on 
execution of a READ statement with the SET 
option. When the REWRITE statement is 
executed, if the embedded key is the same 
as the saved key, a PUTX macro instruction 
is issued. If the key has changed, the 
PUTX macro is not issued and the KEY 
(specification) condition is raised. 


To support the DELETE statement without 
the KEY option, the first byte of the 
logical record is set to X‘FF* and a PUTX 
macro instruction is issued to rewrite the 
record. 


If the file has the KEYED attribute, and 
the mode is INPUT or UPDATE, the QISAM SETL 
function is required in order to reposition 
the indexes. The parameters for the SETL 
macro are such that, for unblocked records, 
the recorded key is transmitted as well as 
the data record. For a READ statement, if 
the KEY string is shorter than the key 
length, the string is placed in an area 
addressed by TPKA in the FCB. If the file 
is not KEYED (indicating that the KEY 
Option will not be employed), the QISAM 
SETL routine is not loaded during the open 
process. | 


Since buffers are employed, truncation 
Or padding of records is performed during 
the move between the buffer and the record 
variable. Padding bytes are undefined in 
value. 


Closing a data set being created or 
updated by QISAM may cause output records 
to be written. If an error occurs, output 
entry to the SYNAD routine is prevented by 
the close process having cleared the 
DCBSYNAD field before issuing the CLOSE 
macro. The operating system uses the ABEND 
macro to terminate the task. 
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BISAM in a Non-Multitasking Environment 
(IHEITE/IHEITM): When the TASK option is 
not employed, direct access of INDEXED 
files, both exclusive and non-exclusive, is 
performed by modules IHEITE/IHEITM. For an 
exclusive file, IHEIOG treats the UNLOCK 
statement as ‘no operation’ (although it 
may implicitly cause the file to be 
opened); the NOLOCK option is ignored by 
IHEITE/IHEITM. 


BISAM requires the use of DECBs to 
communicate information regarding each I/0 
operation requested of it; see ‘I/O Control 
Block (IOCB)* for details of the DECB and 
its use in BISAM. 


Since the EVENT option may be employed, 
and, moreover, the KEYFROM or KEY 
expression may yield a character-string 
value in temporary storage, the key value 
is moved into the buffer before BISAM is 
invoked. Truncation or padding of the 
character-string key to conform to the 
KEYLEN specification is performed during 
the move. A further reason for the move is 
that BISAM may destroy the contents of the 
key and record fields when adding new 
records to a data set. 


If the data set consists of unblocked 
records, a READ statement need not precede 
a REWRITE statement. If blocked records 
are used, the sequence must be READ, then 
REWRITE, since the READ macro instruction 
has the KU parameter, and BISAM requires 
this type of READ to be rewritten. The 
WRITE K macro instruction used to rewrite 
the updated block must address the same 
DECB(IOCB) as that used for the READ KU 
macro instruction. This is achieved by not 
freeing the IOCB used for the READ 
operation. On the next operation on the 
file, a check is made for such an IOCB: if 
one exists, and the operation is not a 
REWRITE specifying the same key, the ERROR 
condition is raised. 


A DELETE statement is implemented by 
first issuing a READ KU macro instruction, 
then setting the first data byte to X'FF', 
and finally rewriting the record with a 
WRITE K macro instruction. 


BISAM in a Multitasking Environment 
(IHEITH/IHEITO): To ensure that the 


initialization and chaining of event 
variables, IOCBs, and exclusive blocks 
cannot be interrupted, the interface module 
IHEINT raises the dispatching priority of 
the current task to its limit before 
calling IHEITH/IHEITO. IHEITH/IHEITO 
restore the priority to its original value 
before executing an I/O macro instruction. 
The formats of the event variable and the 
exclusive block are described in Appendix 
I, which also includes an example of the 
chaining of these blocks. 
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For non-exclusive files, modules 
IHEITH/IHEITO perform the same functions as 
IHEITE/IHEITM, and in addition chain any 
event variables that are made active. Each 
event variable is placed in.a chain 
anchored in the pseudo-register IHEQEVT in 
the PRV for the current taSk. This chain 
enables I/0 eVent variables for which a 
WAIT statement has not been executed to be 
set complete, inactive, and abnormal when 
the task is terminated. 


The implementation for exclusive files 
includes the following additional features: 


1. Files with unblocked records: When any 
operation referring to a record 
(except WRITE and UNLOCK) is 
initiated, the chain of exclusive 
blocks anchored in the TXLV field of 
the FCB is searched for an existing 
exclusive block established in the 
current task for the record. If one 
exists, the lock statement count 
(xSTC) in the exclusive block is 
incremented by one. If there is no 
exclusive block, one is created in 
Subpool 1 and inserted in the task 
chain (anchored in pseudo-register 
IHEOXLV in the current task) and the 
file chain (anchored in the TXLV field 
of the FCB of the current file). The 
lock statement count is set to one, 
and the lock bit (XLOK) to one (unless 
the operation is READ with NOLOCK), 
and the resource is enqueued (i.e. 
the record is locked). After control 
of the resource has been obtained, it 
is dequeuved if XLOK = 0. The qnane 
and rname given in the ENQ and DEQ 
macro instructions are: 


qname (two words): 


Byte 0: Zero 
Bytes 1-3: A(FCB) 
Bytes 4-7: Zero 
rname (one word): 
Byte 0: X"03° 
Bytes 1-3: A(Record key) 


After the CHECK macro instruction for 
the I/O operation has been executed 
(i.e., on execution of the WAIT 
statement if the EVENT option is 
used), IHEITH/IHEITO raise the 
priority of the current task to its 
limit, decrease the lock statement 
count by one, and then: 


1. If the record is no longer locked 
(XLOK=0) and the lock statement 
count is zero, dechain and free 
the exclusive block. 


2. If the record is still locked 
(XLOK=1), unlock it (unless the 
statement is READ without the 


NOLOCK option), and set XLOK to 
zero. If the lock statement 
count is zero, they then dechain 
and free the exclusive block. 


IHEITH/IHEITO then restore the 
dispatching priority to its original 
value. When processing V-format 
records using IHEITO, the READ, WRITE, 
REWRITE, and DELETE statements are 
restricted as in 2 below. 


2. Files with blocked records: To prevent 
other tasks interfering with the READ, 
REWRITE sequence, each READ, WRITE, 
REWRITE, and DELETE statement is 
enqueued on the same resource (i.e., 
there is only one exclusive block for 
each file in each task, and it is not 
freed until the file is closed). 
Control of the resource is retained by 
a given task until the WRITE, REWRITE, 
or DELETE operation is completed; or, 
if the resource was enqueued by a READ 
Operation, until a REWRITE or UNLOCK 
statement is executed. When a READ 
statement with the NOLOCK option is 
executed, the resource is dequeued 
immediately after the task gains 
control of it. 


The qname and rname given in the ENQ 
and DEQ macro instructions are: 


qname (two words): 


Byte 0: Zero 
Bytes 1-3: A(FCB) 
Bytes 4-7: Zero 


rname (one word): 
Byte 0: | X'03° 
Bytes 1-3: A(FCB) 


Apart from these differences, the . 
implementation is as for files with 
unblocked records. 


REGIONAL Data Sets 


The access methods employed for these 
Organizations are BSAM and BDAM, as 
follows: 


BSAM: Creation and SEQUENTIAL access 
BDAM: DIRECT access 


Keys supplied by the source code are 
termed ‘source keys‘. These have two 
formats, one of which is interpreted in two 
ways: 


Source key 


Organization format 
REGIONAL (1): 
Relative record addressing, 
without recorded keys A 
REGIONAL (2): 
Relative record addressing, 
with recorded keys B 
REGIONAL (3): 
Relative track addressing, 
with recorded keys B 
Key Format A: 
ee ee 1 
| M | 
ee eee ate ies J 
<------~-~-------- L-~-—---~-—---+--~ > 


L = Length of key (1 through 255 
bytes) 
M = Key value 


Only the characters blank and 0 to 9 may 
be used in M, which, when converted to 
binary, is the relative record position, as 
required for the BDAM BLKREF parameter. 

The last eight characters are scanned for 
an unsigned decimal integer representation; 
if less than eight characters exist, only 
the available characters are scanned, from 
left to right. 


When a format-A source key is required 
for the KEYTO option, the relative record 
position of the current record is converted 
from a binary count field into character 
representation and is assigned to the last 
eight characters of the KEYTO character 
string variable. If the variable has fewer 
than eight characters, the converted value 
is assigned, right to left, to the KEYTO 
variable. Format A keys are not appended 
to data set records as recorded keys. 


Key Format B: 


Pr 
! 
i 
! 
! 
t 
5 
{ 
! 
t 
! 
{ 
{ 
! 
| 
ie aa 
a | 
! 
t 
! 
t 
! 
t 
! 
! 
} 
i 
t 
f 
i 
fn 


L = Length of key (1 through 255 
bytes) 

M = Last eight characters in the 
source key 

C = The remaining characters in the 
source key other than the M 
characters 


M consists of up to 8 characters, which 
can be blanks or 0 to 9. When converted to 
binary, it represents either the relative 
record position (REGIONAL (2)), or the 
relative track position (REGIONAL (3)). 
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If L < 8, C does not exist. The C 
characters can be any of the 256 characters 
available; they are not scanned. 


The format-B source key is appended to 
Output records when they are added to the 
data set; the number of characters in the 
appended (recorded) key is determined by 
the KEYLEN specified for the data set. If 
KEYLEN is less than the length of the 
source key, the latter is truncated when 
appended to its record; if greater, the 
source key is padded with blanks. 
Similarly, when retrieving keyed records, 
the source key is altered to conform to 
KEYLEN. This permits 1 though L characters 
to be used as the recorded key. The M 
characters might thus be used only for 
computation of the relative record or track 
position. 


BSAM (IHEOPZ, IHEITC, IHEITB): Creation 
and sequential access of REGIONAL data sets 
employs this access method. 


SEQUENTIAL creation is performed by the 
module IHEITC, which adds records to the 
data set in physically sequential record 
and track positions. This module also 
inserts dummy records, as required, by the 
user incrementing the source key position 
information by a value greater than one. 


When a sequentially created REGIONAL 
data set is closed, the current space 
allocation (which may be either the initial 
or a secondary allocation) is completed: 


1. by writing dummy records (F-format 
only), or 


2. by setting the capacity records of the 
remaining tracks to indicate empty 
tracks. 


An FCB history flag (TMET) is turned on 
when, after writing a record, this record 
is seen to be the last one of an extent. 

If this flag is off, the close process will 
continue the initialization until an 
end-of-extent condition is met. 


When LOCATE statements are used to 
create a REGIONAL data set, an IOCB is 
selected from the pool in the normal 
manner. The KEYFROM string is evaluated, 
and all necessary formatting of the data 
set is done, before the pointer is set and 
control is returned to compiled code. To 
ensure that the record is always aligned on 
a doubleword boundary, the open process 
rounds up the keylength to a doubleword and 
allows space in the IOCB for the keylength 
and the block size. Module IHEITC places 
the key right-aligned in the key area, thus 
ensuring that the key and data are in 
contiguous areas, and that the data is 
aligned on a doubleword boundary. 
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The record is not actually transmitted 
until the next statement on the file (e.g., 
CLOSE, WRITE, LOCATE) is executed. If it 
is found on transmission that there is no 
room for the record in the region 
(REGIONAL(3) V and U format records only), 
the capacity record is written and the KEY 
sequence error condition is raised. On 
normal return from the on-unit, control 
passes to the next statement. If this 
occurs when a file is closed implicitly (on 
termination of a task) or explicitly, a 
warning message is printed and the file is 
closed (after the initialization of the 
current extent has been completed). Note 
that it is therefore possible that the 
original record associated with the LOCATE 
Statement may not have been written. 


DIRECT creation requires the 
initialization of the data set during the 
open process; this is performed by the 
module IHEOPZ. Subsequently, records may 
be added to the data set in a DIRECT 
fashion using module IHEITF or IHEITJ. 
Initialization of a data set for DIRECT 
creation causes: 


1. the initial space allocation 
(secondary allocation is ignored) to 
be written with dummy records 
(F-format records, for all REGIONAL 
types), or 


2. the capacity record of each track of 
the initial space allocation to be set 
to indicate empty tracks (U-format or 
V-format records, REGIONAL (3), only). 


If recorded keys are required, dummy keys 
(initial byte X‘FF*, remaining bytes | 
undefined) are also written for F-format 
records only. If during the initialization 
for DIRECT creation an error arises, the 
UNDEFINEDFILE condition is raised, the type 
of error being indicated by the ONCODE 
value. 


As SEQUENTIAL access of a REGIONAL data 
set (module IHEITB) is performed with BSAM, 
it is not possible to support the KEY 
Option on the READ statement. The KEYTO 
option is supported as follows: 


REGIONAL (1): 
A counter (the TREL field in the FCB) 
beginning at zero, is incremented as 
each record, including dummy or deleted 
records, is read; this is converted to 
character string representation and 
assigned to the KEYTO variable. 


REGIONAL (2) and (3): 
The recorded key is read in with the 
record, and assigned, without 
conversion, to the KEYTO variable. 
Transmission of the recorded key only 
occurs if the file has the KEYED 
attribute; otherwise the KEYLEN DCB 
field is forced to zero to prevent 
input of keys (since, for F or U 
records, there are no hidden buffers). 


For both SEQUENTIAL creation and access, 
BSAM requires the use of DECBs to 
communicate information regarding each I/O 
operation requested of it; see ‘The I/O 
Control Block (IOCB)' for details of the 
DECB and its use for BSAM. When REGIONAL 
data sets with the UNBUFFERED attribute are 
accessed (IHEITB) or created (IHEITC), 
hidden buffers are present in all cases 
except for REGIONAL(1), Since the key and 
data must be within a contiguous area in a 
buffer. 


When reading REGIONAL data sets 
sequentially, BSAM retrieves all records 
within the data set, whether dummy 
(deleted) or actual records. For REGIONAL 
(2) and (3) data sets, the library prevents 
dummy (deleted) records being passed to the 
PL/I program. This is achieved by 
inspecting the initial byte of the recorded 
key as transmitted to the hidden buffer. 
(Hidden buffers are always required for 
KEYED SEQUENTIAL access of REGIONAL (2) and 
(3) data sets, because BSAM requires that 
the recorded key and the record be 
transmitted into contiguous storage areas.) 


If the initial byte is the dummy, or 
deleted, code (X'FF'), the IOCB chain is 
reorganized to move each input request down 
one entry in the chain; this resynchronizes 
the READ statements with the actual 
records. The reorganization occurs each 
time such a flagged key is detected. This 
technique is not available for REGIONAL 
(1), since for this type of organization: 


1. there is no way of knowing whether the 
records are actual or dummy, since 
there are no restrictions regarding 
the initial byte of the data record, 
and 


2. there are no recorded keys. 


When a READ statement with the SET 
option is executed for REGIONAL files, the 
data is always aligned on a doubleword 
boundary in the IOCB buffer. 


BDAM(IHEITF and IHEITJ): 


DIRECT access to 
a REGIONAL data set employs this access 
method, the usage depending upon the 
REGIONAL type: 


REGIONAL (1): 
Relative record (block) addressing, 
no key argument 


REGIONAL (2): 
Relative record (block) addressing, 
with key search argument 


REGIONAL (3): 
Relative track addressing, 
with key search argument 


In the instance of REGIONAL (2) and (3), 
the “extended search" feature is always 
employed. A user may control the effects 
of extended search by using the DCB 
subparameter LIMCT; a value may be 
specified to limit the number of records or 
tracks which are searched for a given keyed 
record, or for space to add one. Unless so 
limited, searching for records extends 
throughout the complete data set. 


The BDAM access method requires the use 
of DECBs to communicate information 
regarding each I/O operation requested of 
it; see ‘I/O Control Block (IOCB)* for 
details of the DECB and its usage for BDAM. 
If V format records are used, any IOCB 
created will contain a hidden buffer. 


The BDAM CHECK macro is issued to check 
that the operation is complete. If an 
error is found, the BDAM modules enter the 
IHEITF SYNAD routine, where the error is 
interrogated. 


If the TASK option is not used, direct 
access Of REGIONAL files, both exclusive 
and non-exclusive , is performed by module 
IHEITF. For an exclusive file, IHEION 
treats the UNLOCK statement as ‘no 
operation’ (although it may implicitly 
cause the file to be opened); the NOLOCK 
option is ignored by IHEITF. 


If the TASK option is employed, module 
IHEITJ is loaded instead of IHEITF. The 
difference between these modules is the 
Same as that between IHEITE and IHEITH for 
unblocked records. (See ‘BISAM in a 
Multitasking Environment’. ) 


TELEPROCESSING Files 


The implementation of the teleprocessing 
feature employs the queued teleprocessing 
access method (QTAM), which handles the 
transmission of messages between the 
operating system and remote terminals. 
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Messages accessed by QTAM are handled by 
two kinds of program: 


1. the message control program, and 
2. the message processing program. 


PL/I supports the message processing part 
of QTAM through process queue facilities, 
full descriptions of which can be found in 


IBM System/360 Operating System: QTAM 
Message Processing Program Services and IBM 
System/360 Operating System: QTAM Message 
Control Program. 


QTAM (IHEITP): To the PL/I user, the 
process queues appear as TRANSIENT 
SEQUENTIAL RECORD FILES, and are processed 
by means of the PL/I READ, WRITE and LOCATE 
statements. 


Additional language required for this 
feature is: 


TRANSIENT file attribute on DECLARE or 
OPEN statements. 
ON PENDING (filename) on-unit. 


Note: the TRANSIENT attribute conflicts 
with the following attributes: - 


STREAM 
PRINT 
UPDATE 
DIRECT 
BACKWARDS 
EXCLUSIVE 
UNBUFFERED 


New environment options required are: 


G(max. length) : record format is a whole 
message, or 

R(max. length) : record format is a 
segment from a message 

(max. length being the maximum size of 


message segment or record to be read. This 
value will be set in the halfword DBLK of 
the DCLCB, with information on the format 
(G or R) and an indicator showing the file 
to be of teleprocessing organisation (see 
Appendix I)). 


Bit 0 of flag B (the second byte) of the 
open control block (OCB) will be set if the 
TRANSIENT attribute appears in the OPEN 
statement, and bit 4 of the DCLB byte of 
the DCLCB will be set if it appears in the 
DECLARE statement. 


The options KEYTO (character 
string-variable) and KEYFROM (expression) 
are also acceptable under a teleprocessing 
environment, used with record I/O READ, 
WRITE and LOCATE statements. The compiler 
deals with these statements as discussed 
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under ‘Record Oriented I/0' in this 
chapter. 


OPEN/CLOSE Functions_in_Teleprocessing 


OPEN: the open process will be the same as 
for other record-oriented files discussed 
earlier in this chapter with the following 
additional functions:- 


1. Test for conflict between TRANSIENT 
and other attributes 


2. Create an FCB as previously but with a 
DCB for OTAM. The max. length value, 
as specified in the ENVIRONMENT 
attribute, will be placed in the field 
DCBSOWA of the DCB, and the number of 
buffers specified in the ENVIRONMENT 
attribute will be set in the DCBBUFRC¢ 
field. (If no buffers are specified, 
the default number is two.) 


3. Take the DCB exit as for other files 
and test the following fields: 


a. DCBBUFRO - if this is still not 
set, either by the ENV attribute 
or by DD card, then apply the 
default of two 


b. DCBSOWA - if this field is empty, 
because the max. length has not 
been set in the ENV attribute, 
raise the undefined file condition 


c. DCBRECFM - if the record format 
has not been specified, raise the 
undefined file condition. 


4. Assuming the tests carried out above 
do not raise error conditions, the 
OPEN exit routine additionally issues 
a GETMAIN macro instruction for an 
area large enough to hold the longest 
terminal identification plus the max. 
length of message plus four bytes for 
control information for QTAM 
(8 + DCBSOWA + 4). The address of 
this area will be held in the DCBTRMAD 
field of the DCB. The first eight 
bytes of the GETMAIN area will be used 
for holding the terminal name, and the 
remainder as an intermediate (dummy) 
buffer for messages. The address of 
the ‘message buffer’ will be kept in 
the FCB (in the TSWA field). 


5. Load the teleprocessing transmitter 
module IHEITP and set the first word 
in the FCB for valid statements as is 
the case for other files. The bits: 
set and the statements they refer to 
are: 


bit 1 - READ SET KEYTO 
bit 4 - READ INTO KEYTO 


for input: 


for output: bit 14 - WRITE FROM KEYFROM 
bit 23 - LOCATE SET KEYFROM 


CLOSE: The close process again will be 
Similar to previously described functions, 
but additionally will check to see if the 
last operation on the file was LOCATE. If 
so, the close module will invoke the 
transmitter to write out the last record. 
This is in line with the general rules of 
‘the PUT MOVE mode which is used by this 
implementation. 


The close routine, after the last record 
is written out, will delete module IHEITP 
which was loaded at OPEN time. 


I/O Statements for Teleprocessing 


All I/O statements on TRANSIENT files 
invoke module IHEITP through modules IHEION 
(non-multitasking) and IHEINT 
(multitasking). The latter two modules 
will carry out tests on the validity of 
such I/O statements as described under 
"General Logic and Flow" in this section. 


Input: The transmitter will issue a QTAM 
*GET' macro instruction to read the next 
sequential instruction on the file, and 
record and terminal identification will be 
placed in the ‘dummy’ buffer. The length 
of the data read will be found in the first 
two bytes of the four byte control 
information area. For SET options, the 
pointer will be set to voint to the data in 
the dummy buffer. The data will be aligned 
On a doubleword boundary. 


The terminal identification will be 
moved into the KEYTO string. If the length 
of the identification field is less than 
the KEYTO length, it will be padded with 
blanks, unless the KEYTO string is varying, 
in which case only the current length will 
be set. If the length of the 
identification field is greater, it will be 
truncated. 


Output: The sequence of operations for 
output is very similar to those for input, 
using a QTAM ‘PUT’ macro instruction 
instead of ‘GET’. The data and terminal 
identification are placed in the dummy 
buffer in the same way, with the control 
information set; additionally, the third 
byte of the control information will be set 


to X'02' to indicate the end of the 
message. 


Only the first eight characters of the 
KEYFROM string will be moved into the 
buffer. If there are less than eight 
characters in the string, the string will 
be padded with blanks to fill all eight 
positions. The RECORD condition will be 
raised (when necessary) in accordance with 
the rules for V-format records. 


Error Handling 


With the addition of the ON-conditions 
listed below, the error handling routine 
for teleprocessing files follows the same 
course as for other record-oriented files 
(for a discussion on ON-conditions, see 
chapter 6: “Error and Interrupt Handling"). 


The ON-conditions associated with 
teleprocessing are: 


1. ON TRANSMIT (filename) - could be 
raised for input only 


2. ON RECORD (filename) - could be raised 
as for other files. The records ina 
teleprocessing file would be treated 
as V-format records with the 
corresponding rules applying. 


3. ON ERROR - could be raised as for 
other files with one additional 
condition. If the KEYFROM string is 
invalid or missing, then an error 
condition with an ONCODE of 1020 will 
be raised. 


4. ON PENDING - is very similar to the ON 
ENDFILE condition, with QTAM passing 
control to the user through an EODAD 
exit routine. If EODAD is not 
supplied, then QTAM ‘waits’ until more 
data is available. The normal return 
from the on-unit which implies this 
‘wait’ will be implemented as follows: 


ae Take EODAD exit 


be. Raise PENDING condition (when 
normal return, then) 


ce. Zero EODAD field and re-execute 
GET macro 


a. Reset EODAD to the correct exit 
routine address. 
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CHAPTER 4: PL/I OBJECT PROGRAM MANAGEMENT 


INTRODUCTION 


The PL/I Library provides facilities for 
the dynamic management of PL/I programs. 
This involves: 


1. Program management: Housekeeping at 
the beginning and end of a program or 


at entry to and exit from a block. 


2. Storage management: Allocation and 
freeing of storage for automatic and 
controlled variables, and for list 
processing. 


This section describes the requirements 
for these facilities and their 
implementation by the library. With the 
exceptions of the compiler optimization 
routine and storage management for list 
processing, all the functions described are 
performed by module IHESAP, whose entry 
points are listed in Figure 16; full 
details are given in Chapter 9. Object 
program management in a multitasking 
environment is discussed in Chapter 5. 

Ent int Function 
IHESADA Get DSA 

IHESADB Get VDA 

IHESADD Get controlled variable 
IHESADE Get LWS 

IHESADF Get library VDA 

IHESAFA END 


ITHESAFB RETURN 
IHESAFC GO TO 
IHESAFD Free VDA/Free LWS 
ILHESAFF Free controlled variable 
IHESAFQO Abnormal program termination 
IHESAPA 
IHESAPB Program initialization 
IHESAPC 
IHESAPD 
IHESARA Environment modification 
ITHESARC Setting of return code 
IHESATA STAE exit for O/S abnormal 
termination 
| Figure 16. IHESAP Entry Points 


Program Initialization 


Certain functions must be carried out on 
entry to a PL/I program before the PL/I 
main procedure is given control. One of 
the library program-initialization 
subroutines is always given control by the 
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supervisor on entry to the program. Its 
functions are: 


1. Allocation of storage for the PRV. 
(See ‘Communications Conventions: in 
Chapter 2.) 


2. Initial allocation of LWS. 


3. Passing of the address of the library 
error-handling subroutine (IHEERR), 
which assumes control when an 
interrupt occurs, to the supervisor. 


Block Housekeeping: Prologues and Epilogues 


Prologues and epilogues are the routines 
executed on entry to and exit from a PL/I 
procedure or begin block. The library 
subroutines contain those sections that are 
common to all prologues and epilogues. The 
functions of the library prologue 
subroutine are: 


1. To preserve the environment of the 
invoking block. 


2. To obtain and initialize automatic 
storage for the block. 


3. TO provide chaining mechanisms to 
enable the progress of the program to 
be traced. A detailed description of 
the chaining mechanisms employed is 
provided below. 


The main functions of the epilogue 
subroutine are: 


1. To release storage for the block. 


2. TO recover the environment of the 
invoking block before returning 
control to it. 


storage Management 


In IBM System/360 Operating System, storage 
is obtained or freed by using the GETMAIN 
and FREEMAIN macros. The library assumes 
responsibility for obtaining and freeing 
storage in this way in order to: 


1. Provide an interface between compiled 
code and the control program. 


2. Reduce the overhead involved in making 
a supervisor call every time storage 
is obtained and freed. 


3. Set up chaining mechanisms for dynamic 
storage. 


There are three types of dynamic storage 
in PL/I, controlled, automatic, and based. 
Based storage is discussed in ‘List 
Processing: Storage Management". 


Operating-System Facilities 


The following facilities appropriate to 
this chapter are provided by IBM System/360 
Operating System. (See IBM System/360 


Operating System: Supervisor and Data 
Management Macro Instructions. ) 





SPIE macro instruction: Specifies the 
address of a routine to be entered when 
specified program interrupts occur. 


STAE macro instruction: specifies the 
address of a routine to be entered when a 
task terminates abnormally. 


ABEND macro instruction: Causes a job step 
or task to be terminated abnormally. 


Write To Operator (WTO) macro instruction: 
Can be used to write a message on the 


operator's console. 


R-type GETMAIN: Requests that the 
supervisor allocate a contiguous block of 
main storage to the caller. A subpool 
number should be specified. (See below.) 


R-type FREEMAIN: Releases a main storage 
area. The length, subpool number, and 
address of the beginning of the area must 
be specified. 


Subpools: Subpool numbers are of 
Significance only in an operating system 
with MVT. 


Subpool zero 
The storage in subpool zero is allocated 


on a job-step basis, and is never 
automatically released until the end of 
the job step. 


Subpool non-zero 
The storage in a subpool with a non-zero 


number is allocated on a task basis, and 
is automatically released on the 
termination of the task that owned the 
subpool. 


IBM System/360 Operating System: 


Supervisor and Data Management Services 
contains a full discussion of 


main~storage management. 
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AUTOMATIC STORAGE: STORAGE MANAGEMENT 


Two types of automatic storage area are 
needed to implement the functions described 
above. These are: 


1. The storage area associated with the 
execution of a PL/I block, known as a 
dynamic storage area (DSA). 


2. The storage area mainly used for 
automatic variables whose extents are 
unknown at compile time, known as a 
variable data area (VDA). 


Each type of storage area is identified by 
flags set in the first byte. These flags 
also indicate the existence of certain 
optional entries in the storage area. The 
flag patterns are shown in Appendix J. 


Dynamic Storage Area_ (DSA) 


This area, always associated with the 
execution of a PL/I block, is used to 
record the progress and environment of a 
program. It also contains space for 
AUTOMATIC variables declared in the block 
and for various optional entries. The 
minimum size of a DSA is 100 bytes. The 
format is described in Appendix J. 


The address of the DSA associated with a 
particular block is held in a 
pseudo-register. Hence there is a 
pseudo-register for each block; the group 
of these pseudo-registers is known as the 
display. The address contained ina 
display pseudo-register can be used to 
identify the DSA associated with a 
non-recursive block when a GO TO statement 
specifying a label in that block is 
executed. 


When a block is entered recursively, a 
new DSA is created for the invoked block. 
The address of the DSA associated with the 
previous invocation of that block is stored 
in the display field of the new DSA. This 
address is already stored in the 
appropriate pseudo-register, where it is 
now replaced by the address of the new DSA. 
When this latest invocation is finished, 
the new DSA is freed and the address of the 
previous DSA is restored to the appropriate 
pseudo-register. 


; When there is a GO TO statement to a 
label in a recursive block or to a label 
variable, a unique means of identifying the 
block containing the label is needed. This 
is accomplished by means of an invocation 
count, which is stored in the 
invocation-count field in the DSA during 
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the prologue. The current invocation count 
is contained in a pseudo-register and is 
increased by one each time a DSA is 
obtained. 


Variable Data Area (VDA) 





A variable data area is a special type of 
automatic storage area used for variables 
whose extents are not known at compile 
time. This storage area is associated with 
the storage obtained for a particular 
block. The only housekeeping necessary is 
that which provides a means of 
identification of the type of storage area 
and a method of associating it with a 
particular block for epilogue purposes. 


VDAS are used for three other purposes: 


1. Temporary storage for library modules. 
These areas are only distinguishable 
from an ordinary VDA by the flag byte. 
This is to allow them to be freed on a 
GO TO, as described in the example in 
"DSA Chain' under ‘Block 
Housekeeping’. 


2. The PRV and primary LWS are contained 
in a VDA known as the PRV VDA which is 
chained back to the external save 
area. 


3. Secondary LWS is contained in a 
special library workspace VDA. 


The formats of the VDA, PRV VDA, and LWS 
VDA are shown in Appendix J. 


Library Workspace (LWS) 


The housekeeping associated with library 
workspace can be divided into two parts: 


1. The identification of the area needed 
as library workspace, and chaining 
this to a previous allocation of 
automatic storage and to any previous 
library workspace. 


2. The updating of the pseudo-registers 
pointing at the various areas in 
library workspace. 


The first allocation of LWS is contained 
in the PRV VDA; subsequent allocations are 
contained in the LWS VDA. The 
pseudo-register IHEQLSA always contains the 
address of the current LWS. Save areas 
within LWS are indicated thus: 


1. The address of each save area is held 
in a pseudo-register. 
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2. The beginning of each save area is 
indicated by X‘'60" in the first byte. 
(A DSA can often be readily 
distinguished from a save area in LWS 
by the presence of X'8' to X'F' in its 
first half byte. Appendix J includes 
the format of the first byte of the 
DSA.) 


Allocation and Freeing of Automatic Storage 


This section describes the methods of 
controlling the allocation and freeing of 
automatic storage for VDAs, DSAs and 
secondary LWS. 


To minimize the number of supervisor 
calls necessary to obtain automatic 
storage, a fairly large block of storage is 
Obtained every time a call is made. Areas 
are allocated by the library from this 
block as required until a request is made 
that is too big to be satisfied from the 
remaining storage in the block. Another 
block is then obtained by a call to the 
Supervisor. So that a check can be made as 
to whether the amount of storage remainina 
in a block is sufficient to meet an 
allocation, a record of the amount is 
stored in the block. When a storage area 
is freed, its length is added to the 
available length in the block. When the 
available length equals the total length of 
the block, the block is returned to the 
supervisor. 


Since storage areas are released in the 
reverse order to their allocation, a 
chain-back mechanism, with a pointer to the 
last member of the chain, is provided. 


Initially, storage is allocated for the 
PRV VDA from a 4k or a 6k block. When 
further requests are made for storage, they 
are satisfied by allocations from the 
remaining storage of this block. When a 
request cannot be satisfied, a 2k block (or 
a block containing a multiple of 2k bytes) 
is obtained by means of a GETMAIN macro. 
This block is chained to the existing block 
by the free-core chain. (See Figure 17.) 


In any block that contains unallocated 
Storage (that is, contains free core), the 
first four words of the unallocated storage 
are used for control purposes: 
ist word: Length (in bytes) of the 
unallocated storage for that 
block (excluding the four 
control words) 


2nd_word: Block length 


3rd word: A(Free core length in previous 


block) 


rr ey 7 (eS SSS ee ee Ram ah a ai al as 1 
i PRV | | 2k_ block | | 2k_ block | 
| | | | | | 
{ | | Used core | i Used core { 
| | | | | | 
p---~------—------------4<---) | | | 
| | {| | | 
}----------------- -----{ | | | | 
l | | | | | | 
f---------—----------- || | | | 
| | | | | | | 
p----------------------{ || | | 
I IHEQSFC t---1 |_| | | 
}----------------------{  '4->}---------------------- {<----; | | 
| [ ; | L(Free core) | i | | 
| | 9 | f++--+-----------------4 | | | 
| | | | Block length { |} | 
[| 9 | f----------------------4 | | | 
| [ t--{ Chain-back pointer | | | | 
| ~~---~-~-------------- = | 
| | | Chain-forward pointer}---, | | | 
| | }---------------------- { —- te > f---------------------- : 
| | | | 1 | L(Free core) | 
| | | | | }---------------------- { 
| | | Free core | | | Block length | 
| | | | | }---------------------- { 
| | | | t-4 Chain-back pointer | 
| | | | }---------------------- { 
| | | | | zero | 
| | | | }---------------------- { 
| | | | | 
| | | | | Free core | 
[ | | | | | 
| | | | | | 
| | | | | | 
bee eee (peepee ee J ecto Seo eed 
Figure 17. Structure of the Free-Core Chain for Automatic Variables 
4th word: A(Free core length of following satisfied from that block. The free-core 
block) length and pointers are adjusted, as are 
the appropriate pointers in the blocks on 


The first and last blocks require a either side. 
Slightly different usage: 
When storage is freed, the pointers are 


First block: Uses the free~-core adjusted, and the free-core field in the 
pseudo-register IHEQSFC in corresponding block is updated. If a 2k 
the chaining forward and block becomes available, it is freed by 
back: issuing a FREEMAIN macro, and the free-core 


chain pointers are adjusted accordingly. 
1. IHEQSFC contains 
A(Free-core length of 
first block). 
CONTROLLED STORAGE: STORAGE MANAGEMENT 
2. 3rd word of block 


contains 

(ACIHEQSFC) - 12), which Controlled storage is used for controlled 
is a dummy free-core variables only; it is requested by the 
length in the PRV. ALLOCATE statement and freed by the FREE 


statement. 
Last block: 4th word contains 0 
Allocation of a particular controlled 


When a request for storage is received, variable may occur a number of times. 
a search of the free-core lengths, starting Since the latest allocation is always the 
from the first, is made. If a free-core one to be used it is convenient to have a 
length equal to or greater than the length pseudo-register pointing at it; this 
requested is found, the request is pseudo-register is sometimes referred to as 
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ALLOCATION 2 


ALLOCATION 1 


gaa ec aan | (See se a aia, oe et 
| PR | TIC | PR offset] | TIC ] PR offset] 
p--—-----------------] | }---------+---------- }-------~-4----------] 
| | | | Chain-back address }-, | 0 | 
| | [00 pee------------------4 | f--------------------4 
[ | | | Length 14 | Length | 
| | t-->}--------------------+4 l-->}--------—----------- 
| | | | | | 
| | | | | 
| | | | | | 
ee ee eee ee ad bee eee eee Us oi ees J 
Figure 18. Storage Allocation for a Controlled Variable 


an ‘anchor word’. Each allocation is 
chained back to the previous allocation so 
that the pseudo-register can be updated 
when the current allocation is freed 
(Figure 18). The length of the data is 
recorded in the fullword field following 
the chain-back address. The length of the 
data is 12 bytes less than the length of 
the allocation. The Task Invocation count 
is held in the TIC field. 


When there is no allocation, the 
contents of the pseudo-register are zero. 
Each allocation points to the previous 
allocation, the pointer being zero in the 
first allocation, which is at the bottom of 
the stack. Thus the various allocations of 
a particular controlled variable become 
part of a push-down (ALLOCATE) pop-up 
(FREE) list. 


When a request is made to storage 
management for a new allocation, it is 
serviced by issuing a GETMAIN macro. 
Twelve bytes are added to the length 
requested, for control purposes, and this 
new length is rounded up to a multiple of 
eight bytes. 
actual length requested. The 
pseudo-regaster is updated and points to 
word four of the area. When a request is 
made to storage management to free an 
allocation, it is serviced by updating the 
pseudo-register and issuing a FREEMAIN 
macro. 


LIST PROCESSING: STORAGE MANAGEMENT 


This section describes the functions of 
module IHELSP, which controls the 
allocation and freeing of storage for the 
PL/I list-processing facility. The 
functions involved are: 


1. Allocation and freeing of system 
storage for based variables. 
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The length field contains the 


2. Allocation and freeing of storage for 
based variables in programmer-defined 
areas (area variables). 


3. Assignments between area variables. 


System Storage - Based Variables 


‘Storage for based variables is allocated 


and freed in a similar manner to controlled 
storage, but it is not stacked since each 
generation is associated with a particular 
pointer value: reference may be made to any 
current generation of based storage by 
associating the appropriate pointer value 
with the name of the based variable. A 
request for a new generation of based 
Storage is serviced by issuing a GETMAIN 
macro, and storage is freed by the FREEMAIN 
macro. Based storage is allocated only in 
multiples of eight bytes: the sum of the 
length of the variable and its offset from 
a doubleword boundary is rounded up to a 
multiple of eight bytes. All based storage 
allocated in a task is freed at the end of . 
the task. 


The AREA Attribute 





The AREA attribute enables a programmer to 
define a block of storage (an area 
variable) in which he can collect and make 
reference to based data. Space within the 
area variable is requested and released by 
ALLOCATE and FREE statements that include 
an IN(area-variable) clause. Reference can 
be made to a based variable contained by an 
area variable just as if the based variable 
were in system storage. The contents of 
one area variable can be assigned to 
another area variable, and an area variable 
can be handled as a single data item in 
input/output operations. 
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Figure 19. Format of Area Variable 


Free 
Element 


Extent 


Free 
Element 


7 


The Area Variable 


The format of the area variable is shown in 
Figure 19. The start of the area is 
aligned on a doubleword boundary. The 
first four fullwords are used for control 
information, the remainder of the area 
being the storage requested by the 
programmer in declaring the area variable. 
The portion of the area that has been 
allocated to based variables is termed the 
extent. When storage is allocated to an 
area variable, its length is set in the 
last three bytes of the first word, and the 
second word (offset of end of extent) is 
set to zero. 


Area Storage for Based Variables 


Storage for based variables within an area 
variable is allocated only in multiples of 
eight bytes; each such allocation is termed 
an element. The first request for storage 
for a based variable is satisfied by the 
allocation of the appropriate number of 
bytes starting at the beginning of the 
unused space; the offset of the end of this 
allocation is set in the second word of the 
area variable, which now points to the 
first available doubleword of unused 
storage. Providing no storage has been 
freed, further requests are met by further 
contiguous allocations from the unused 
Space, the offset of the end of the extent 
being updated each time. 


If the last allocation of the extent is 
freed, the offset in the second word of the 
AREA variable is reduced. However, if 
allocations other than the last in the 
extent are freed, the extent is not 
reduced: spaces, termed free elements, are 
left. The length of each free element is 
set in its first fullword, and a pointer to 
the next smaller free element (in the form 
of an offset from the start of the area 
variable) is set in the second word. If 
there are no smaller free elements, the 
second word of the free element points to 
the fourth word of the area variable, which 
is set to zero. The chain of free elements 
is termed the free list, and is anchored in 
the third word of the area variable, which 
contains the offset of the largest free 
element. When an area variable contains a 
free list, the first bit of the flag byte 
is set to 1. 


Whenever storage in an area variable is 
to be allocated to a based variable, the 
free list is searched for the smallest 
element that will contain the based 
variable. If no free element is large 
enough, space is allocated from the unused 
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part of the area. If this, also, is too 
small, the AREA condition is raised. When 
an element is freed, it is placed in the 
free list according to its size. If it is 
contiguous with another free element, the 
two are merged and included in the free 
list as a single element. If the last 
element in the extent is freed, the extent 
is reduced and the element is not placed in 
the free list. 


Area Variables - Assigment 


When the contents of area variable A are 
asSigned to area variable B, the current 
extent and the control words (except the 
length of A) are copied into B. If the 
length of B is less than the extent of A, 
the AREA condition is raised. 


The AREA Condition 


If an on-unit is entered when the AREA 
condition is raised during the execution of 
an ALLOCATE statement, the ALLOCATE 
statement is executed again after the 
on-unit has been terminated normally. The 
return address passed by compiled code is 
stored in the library communications area 
(WREA) before the on-unit is entered. On 
normal termination of the on-unit, IHEERR 
returns control to the address in WREA. 


If the AREA condition is raised during 
the execution of an assignment statement, 
the statement is not executed again. 


PROGRAM MANAGEMENT 
Initialization of a PL/I Program 


On entry to a PL/I program, one of the 
library initialization subroutines 
(IHESAPA, IHESAPB, IHESAPC, and IHESAPD) is 
always given control by the supervisor; the 
entry point that is used depends on the 
level of compiler optimization required 
(see below) and on whether the PL/I program 
is called from an assembler-language 
routine. The initialization routine first 
Obtains storage for the PRV VDA. The 
length required is the sum of: 


L(PRV) (passed by the linkage editor) 


L(LWS) (assembled by the initialization 
subroutine) 


8 control bytes 


Since a pseudo-register is referenced by 
the addition of a fixed displacement to the 
base address in register PR, and the 
maximum displacement allowed by the 
assembler is 4096 bytes, the length of the 
PRV is limited to 4096 bytes. This puts 
the upper limit on the combined number of 
blocks, files and controlled variables at 
about 1000. If the initialization routine 
is asked to get a PRV longer than 4096 
bytes, a message is printed out on the 
console and the program is terminated. 


The initialization routine zeros the 
PRV, sets up the LWS pseudo-registers, and 
issues a SPIE macro instruction naming 
IHEERR and a STAE macro instruction naming 
IHESTA. In addition, IHESAPA and IHESAPC 
enable a PARM parameter on the EXEC card to 
be passed to the PL/I program. (See IBM 


System/360 Operating System: Job Control 


Language User's Guide, and Job Control 
Language Reference.) On exit from the 


initialization svbroutine, register RA 
points at a location containing the address 
of the SDV of the parameter. 


Termination of a PL/I Program 


Normal Termination: Normal termination of 
a PL/I procedure is achieved by an END or 
RETURN statement, either of which involves 
releasing the automatic storage associated 
with the procedure. If a request is made 
to free a DSA which would entail freeing 
the DSA for the main procedure, IHESAFA 
(END) or IHESAFB (RETURN) raises the FINISH 
condition and the program branches to the 
error-handling subroutine (IHEERR). If and 
when this subroutine returns control, 
IHESAFA or IHESAFB causes all opened files 
to be closed (by calling the library 
implicit-close subroutine). Subsequently 
all automatic storage, including the PRV 
VDA, is returned to the supervisor. 

IHESARC is then called to set the return 
code and return control to the supervisor. 


Abnormal Termination: A PL/I program is 
considered to terminate abnormally when the 
FINISH condition is raised by any means 
other than a RETURN, END, or SIGNAL FINISH 
Statement (e.g., when an object-time error 
occurs such that the ERROR condition is 
raised). If there is not a GO TO out of 
the ERROR or FINISH on-unit (if any), the 
error-handling subroutine (IHEERR) calls 
IHESAFQ, which closes all the open files in 


the manner described above; IHESAFQ returns 
to the supervisor with a return code of 
(2000 + any return code already set (module 
1024)). 


System Termination: If the operating 
system schedules the abnormal termination 


of a PL/I program, such a termination will 
be intercepted and a message will be output 
on SYSPRINT if possible; alternatively the 
message will be output on the system 
console. Control will then be passed back 
to the abnormal termination routine of the 
operating system. 


GO TO Statements 


In PL/I, a GO TO statement not only 
involves the transfer of control to a 
particular label in a block but also 
requires the termination of Contained 
blocks. The housekeeping requirements for 
this are: 


1. A return address. 


2. A means of identifying the automatic 
storage associated with the block to 
be made current. 


Identification of the appropriate storage 
depends on whether the environment is 
recursive or non-recursive: 


Recursive: A count (the invocation count) 
is kept of the number of times 
any block is entered; this 
count can be used to identify 
the storage for a particular 
invocation. 

Non-recursive: The address of the storage 


for each block is required. 


On-Units and Entry-Parameter Procedures 


If, in a recursive environment, the program 
enters: 


1. an on-unit, or 


2. a procedure obtained by calling an 
entry parameter, 


that environment must be restored to the 
State that existed when the ON statement 
was executed or the entry parameter was 
passed. Similarly, at the exit from the 
on-unit or the entry-parameter procedure, 
the environment must be restored to its 
former state. 


Chapter 4: PL/I Object Program Management 49 


If the on-unit or entry-parameter 
procedure refers to automatic data in 
encompassing blocks, these references will 
be to the generations that existed when the 
ON statement was executed or the entry 
parameter was passed. These will not 
necessarily be the latest generations. 


The correct environment is obtained by | 
restoring the display to what it was at the 
time the ON statement was executed or the 
entry parameter passed. 


When an on-unit is to be entered, the 
library error-handling subroutine calls 
IHESARA and passes it: 


1. The address of the on-unit. 


2. The invocation count of the DSA 
associated with the procedure 
containing the ON statement. 


When an entry-parameter procedure is to 
be called, compiled code branches to 
IHESARA and passes it: 


1. The address of the called procedure. 


2. The invocation count of the passing 
procedure. 


The state of the display at the time of 
passing is determined by examining the DSAs 
of active blocks invoked before the passing 
procedure. The display is modified and 
control is transferred to the called 
procedure. 


Before an on-unit or an entry-~parameter 
DSA is freed, the display is restored, ina 
Similar manner to that described above, to 
the state it had immediately before the 
on-unit was entered or the entry-parameter 
procedure was called. 


Block Housekeeping 


The chaining of automatic storage areas is 
required both for housekeeping purposes and 
for storage management. In general, both 
these functions are satisfied by the 
automatic storage area chain (called the 
DSA chain or ‘run time stack'). When a 
library module is entered, an offshoot of 
the DSA chain, known as the save-area 
chain, may be formed. 


DSA Chain: The DSA chain consists of the 
external save area, PRV VDA, DSAs and VDAs. 
DSAs are added to the chain as procedures 
and blocks are entered. VDAs are added to 
the chain after the DSA of the block in 
which they are required. The 
pseudo-register IHEQSLA is always set to 
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point at the last allocation in the chain. 
Initially it points at the PRV VDA. 
Register DR always points to the current 
save area. 


Consider a sample program. Successive 
areas are added to the chain thus: 
1. PRV VDA 
2. DSA (Main procedure) 
3. DSA (Procedure) 


4. DSA (Begin block) 


PR | PRV VDA }---> »-----------; 
~-->}-----------{ | 
| | | External | 
| PRV | rd | 
IHEQLSA | | | save area | 
——->}-——--——----4_ | | 
| i tl 
| LWS 1 , of t-———--~—--1 
i | 
eee ree 1 | 
A | 
| | 
p-—--1-—----, | 
| | | 
| DSA 1 |<-4 
| (Procedure) | 
| | 
Croce eeeee J 
A 
| 
posse 
| | 
| DSA 2 " 
| (Procedure) | 
| | 
ee | 
A 
| 
---> p--—--1--—--, 
{| DSA 3 { 
| (Begin) | 
| | 
Cae eee nene | 
Figure 20. Example of DSA Chain 


At this stage the storage map is as 
shown in Figure 20. If the begin block 
required a VDA this would be added to the 
end of the chain. Figure 21 shows an 
example in which the begin block required 
two VDAs. If the program now executes: 


1. An END statement: The storage in the 
chain is released, starting with the 
area pointed at by IHEQSLA and 
finishing when the current DSA has 
been released. This leaves the chain 
with items 1, 2 and 3 only. 


2. A_RETURN statement: All areas up to 
and including the immediately 
encompassing procedure DSA are 
released, leaving only items 1 and 2. 


It is also possible to release the 

last VDA ina chain without releasing any 
other areas, by freeing the area pointed at 
by IHEQSLA. 


If a GO TO statement referring to a 
label in the main procedure had been 
executed when the situation was as shown in 
Figure 21, then either the invocation count 
or the display of the main procedure would 
be passed to the library subroutine 
(IHESAFC). This would then search back up 
the chain until it found the DSA with that 
invocation count or display, and then make 
this DSA current. It would then free: 


1. All areas up to and including the DSA 
allocated after the DSA to be made 
current. 


2. Any library VDAs or LWS between the 
DSA to be made current and the 
following DSA. A VDA used by the 
library is distinguished from one used 
by compiled code by the flags in the 
first byte. (See Appendix J.) 


a ie a a a dieeiiiendis aaa | 


| | 
| | 
| | 
| | 
L j 


| 
| 
| | 
Jj 


See eee _eaw G2 en am 


Figure 21. Continuation of the DSA Chain 


Save-Area Chains When a PL/I block calls a 
PL/I Library subroutine, the save area 
passed is that in the DSA for that block. 
If the library routine calls a lower-level 
library routine, the save area passed is 
that of the appropriate level in LWS. Thus 
a Ssave-area chain is built up as an 
offshoot of the DSA chain. (See Figure 
22.) Normally the save-area chain unwinds 
itself as control returns up through the 
levels; in the example, the chain would be 
left with DSAs 1, 2 and 3 remaining. 


aaa ac 1 ca a era 1 
| | | LWS | 
i DSA 3 |<-4 | | 
| | | LSA | 
| f [| DR | | 
L-——————~——— 40 [0 22> $----~------- 4 
A | | | 
| L-.-——— { Save area | 
| | | 
ns aaa 1 | 
| | | | 
| VDA | }----------- ’ 
| | | | 
t_---------- J | 
AN | | 
| | | 
IHEQSLA | | 
<--> pe Seimei 7 | | 
| | | | 
i VDA | L-—---~—~—-—~ j 
| 
aa aay ee J 
Figure 22. Construction of the Save-area 


Chain 


Treatment of Interrupts: When a program 
interrupt occurs in a subroutine (library 
Or compiled code), the librarv 
error-handling subroutine (IHEERR) is 
entered and the address of the save area of 
that subroutine is set in register DR. 

(See Figure 23.) 


IHEERR calls IHESADE, passing its own 
save area, to get a new LWS (LWS2). If 
there is an on-unit corresponding with the 
interrupt condition, then, on return from 
IHESADE, IHEERR branches to IHESARA (which 
modifies the display) and passes it the 
Save area LSA in LWS2. In turn, IHESARA 
branches to the on-unit and passes it the 
Same save area. The prologue for the 
On-unit then calls IHESADA to obtain a DSA. 
The DSA chain can now continue if required. 
(See Figure 24.) 


If there is no on-unit corresponding to 
the interrupt condition, standard system 
action is taken. (See Chapter 6.) 


There are two possible ways of freeing 
the on-unit DSA: 
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By a GO TO statement from the on-unit. 
If the GO TO is to a statement in a 
block associated with DSA 3, or 
earlier, then the save-area chain can 
Simply be forgotten. Registers are 
restored from the DSA to become 
current. 


(S=s<Se5S2—— 1 ac aa Sa ed 
{ | | Lws_1 | 
| DSA 3 |<-5 | | 
| i; tf | LSA | 
Laem J | fp --—--- ----- ] <=, 
A Lo ; | 
| | Save area | | 
| | {| 
| DR | i | 
promwn tn mnrnq tO fen {| 
| | }--4 
| VDA | r->| LWE | 
| ; { | | 
Lemme d [panama { 
A 1 | | 
| | | | 
| | | 
pono a et——---7 || | 
| it { | | 
| VDA ; { | | 
i 1 | | | 
bam mmmmenent || | 
A { | | 
| | | | 
IHEQSLA | een 
m-->p-----4-----) | 
IHEQLSA | LWS VDA | | 
~-->}---------- 4 | 
] LWS 2 }-——4J 
| | 
| LSA | 
}---------- + 
| | 
|Save areas | 
| | 
bo 
Figure 23. Structure of the DSA chain when 
the error-handling subroutine 
is entered after a new LWS has 
been obtained 
2. By the one-unit issuing a request to 
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storage management to free the on-unit 
DSA. When this is done, control is 
returned to the error-handling 
subroutine at the point following that 
from which control was transferred to 
the on-unit. The error-handling 
subroutine restores DR in the normal 
way to point at LWE in LWS 1 and calls 
IHESAFD to free LWS 2. Control is 
then returned to the interrupted 
routine. In the example, the 
situation would now be as in Figure 
22. 





aaa eaten | Gene. 
| | | Lws 1 | 
| DSA 3 |<-4 | | 
| | | | Lsa | 
| lt | | | 
to--------3 | f---------4<-, 
A | | 1 | 
| t.-{Save area| | 
| | { | 
p-—--+----, }--------- | 
| | | { | 
| VDA | r->| LWE }--4 
| 1 | | | 
\--——----- J | f--+------ 4 
A | | | 
| } | | 
| | | | 
poaent———-, || | 
| | | p----—---4 
| VDA {| | | | 
| tf { | | 
t-----——- | | | 
A | | | 
| , | | 
| | | 
peeaataa=-7. [| | | 
| ; t | | 
| LWS 2 }f--1 | | 
| | | 
L-—-—-—--—- ) | | 
A LSjatcteeceeged 
IHEQSLA, DR | 
---> --~--1-—__, 
| | 
{| on-unit| 
| DSA | 
| | 
bose j 
Figure 24. Structure of the DSA chain when 


the on-unit DSA is attached 


Object-time Optimization 


The compiler contains an optimization 


technique which minimizes the necessary 
housekeeping and provides faster execution 


of the prologue and epilogue. The 
technique can only be applied if the 


optimization option (OPT=01.Default) is 
specified for the compilation of the main 


procedure of a program. In this case, 


ina 


non-multitasking environment, a 512-byte 


storage area is reserved at the end of 
primary LWS during initialization and 
pseudo-register IHEQSLA is set to the 
address of that save area. The 
pseudo-register IHEQLWF contains the 


address of the reserved area attached to 


the current LWS. A reserved area is 


released only when its associated LWS is 


released. 


Whenever a DSA is allocated for the 
innermost procedure or procedures (at the 
same depth) of a nest of procedures, the 
optimization technique will try to meet the 
requirement from the reserved area. If 
this is not possible (because the DSA 
requires more than 512 bytes), the required 
storage is obtained in the standard way, 
using IHESADA. 


A DSA allocated in the reserved area, or 
a DSA allocated in STATIC storage at 
compile time, is identified by a ‘one’ in 
the first bit of the second byte. (See IBM 
System/360 Operating System: PL/I (F) 


Compiler, Program Logic Manual for a 
discussion of DSAs in STATIC storage.) 
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CHAPTER 5: PL/I OBJECT PROGRAM MANAGEMENT IN MULTITASKING 


INTRODUCTION 


This section describes the facilities 
provided by the PL/I Library for the 
dynamic management of PL/I multitasking 
programs in an operating system with MVT. 
PL/I multitasking can be used ina 
multijobbing or a multiprocessing 
environment. 


For multitasking, the program management 
module IHESAP is replaced entirely by the 
module IHETSA. Although some of the 
routines in IHETSA are peculiar to 
multitasking, most of them perform similar 
functions to the corresponding routines of 
IHESAP; Figure 25 compares the two modules. 
Only those features of IHETSA that are not 
included in IHESAP are described in detail. 
The library facilities for the multitasking 
pseudo-variables and built-in functions, 
and for the WAIT statement, are described 
at the end of this section; Appendix K 
gives full details of the PL/I control 
blocks for multitasking. 


Function 


Get DSA 

Get VDA 

Get controlled variable 
Get LWS 

Get library VDA 

END 

RETURN 

GO TO 

Free VDA/Free LWS 

Free controlled variable 
Abnormal program termination 


Program initialization 


Environment modification 
Setting of return code 
Initialization of major task 
CALL with task option 


EXTR (abnormal end-of-task exit routine-STAE exit) 


EXIT (PL/I abnormal end-of-task routine) 
Initialization routine for subtask 


PL/I_ TASKS 


All tasks created in a PL/I multitasking 
program are executed as subtasks of a 
common ancestor, the control task. The 
control task is the initial task which 
receives control from the operating system 
at the commencement of program execution. 
The use of a control task ensures that 
there is always present a task with a 
higher priority than that of the major 
task, the task for the main procedure. The 
control task can then be entered whenever 
it is necessary to terminate the major 
task, e.g. on execution of a STOP 
statement. Subsequent tasks attached by 
the major task are known as subtasks. 


The management of all tasks in the PL/I 
program is carried out by the control task. 
It creates and initializes the major task 
and any subtasks required and arranges for 
the termination of these tasks, either 
normally or abnormally. When multitasking 
is used in a multiprocessing environment, 
it is possible that two or more tasks may 
attempt to execute “soft" code (code which 
accesses Or modifies control blocks) at the 


Entry Points 


IHESAP ITHETSA 
IHESADA IHETSAD (Alias) 
IHESADB IHETSAV 
IHESADD See Note 
IHESADE IHETSAL 
IHESADF IHETSAW 
IHESAFA IHETSAE 
IHESAFB IHETSAR 
IHESAFC IHETSAG 
IHESAFD IHETSAF 
IHESAFF See Note 
IHESAFQ LHETSAY 
ITHESAPA IHETSAP (Name) 
IHESAPB IHETSAA (Alias) 
IHESAPC 
IHESAPD 
IHESARA IHETSAN 
IHESARC IHETSAC 
IHETSAM 
IHETSAT 
IHETSAX 
LHETSAZ 
IHESUBA 


Note: The allocation and freeing of controlled storage in a multitasking environment 
is handled by a separate module, IHETCV, which is called by compiled code. 


Figure 25. Comparison of IHESAP and IHETSA 
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same time. So that only one task may 
access "soft" code at any one time, the 
control task treats all tasks as subtasks 
of itself, and supervises these subtasks by 
a series of event control blocks; the POST 
event control block (PECB) and the WAIT 
event control block (WECB) for each task. 

A list of PECBs is kept by the control task 
in an ECBLIST which is checked every time a 
subtask requests access to soft code. When 
a request to execute soft code is made, the 
control task either POSTs the subtask to 
continue (if no other subtask is executing 
the same area of soft code) or, 
alternatively, keeps the requesting task in 
a WAIT state. On completing execution of 
the soft code, the subtask informs the 
control task which is then free to accept 
further requests. 


Note: The "soft" areas of code are those 
concerned with: 


1. Task Attachment 

2. End of task 

3. End of block with attached tasks 
4. PRIORITY pseudo-variable 


5. COMPLETION pseudo-variable and EVENT 
variable assignment 


6. WAIT statement 
7. OPEN statement 
8. CLOSE statement 


9. Exclusive block chaining 


TASK ATTACHMENT AND INITIALIZATION 


CONTROL TASK 


The control task is established at a 
priority (16*JSPRI+11), where JSPRI is the 
priority specified in the JOB statement for 
the PL/I program. The presence of the TASK 
option in the PL/I main procedure statement 
causes the compiler to insert the name of 
one of the initialization routines of 
library module IHETSA into control section 
IHENTRY. At execution time, control is 
passed initially to IHENTRY which then 
branches to the initialization routine 
selected by the compiler (IHETSAA or 
IHETSAP). Execution of the selected 
routine constitutes the control task. The 
control task obtains contiguous storage 
for: 


1. Its own save area and workspace (144 
bytes) 


2. The event control block for the major 
task task variable (60 bytes) 


3. The PRV VDA for the major task. 


The Length required for the PRV VDA is 
the sum of: 


1. Eight control bytes 
2. L(PRV) (passed by the linkage editor) 


3. L(LWS) (the total length of workspace 
initially required by the library) 


4. Four task-oriented words 
(Four 


5. Task Communications Area (TCA) 
words long) 


(If a PRV longer than 4096 bytes is 
requested, a message is printed out on the 
console and the program is terminated.) 


The format for the complete area of 
storage involved, with lengths, is shown in 
Figure 26. (Key numbers corresponding to 
the above are shown on the left of the 
Figure. ) 


Having allocated these storage areas, 
the control task: 


1. Uses the area allocated for the TASK 
variable of the major task, sets it 
active and initializes it, using an 
EXTRACT macro to obtain the limit and 
dispatching priorities from the TCB 
(task control block) set up for the 
control task by the operating system. 
(The TASK variable contains the task 
control information required by the 
PL/I Library). 


2. Creates an EVENT variable for the 
major task and sets it active. 


3. Sets up an ECBLIST (list of PECBs 
currently being waited on) in a 1024 
byte area. The ECBLIST initially 
contains only the address of the PECB 
for the major task. The ECBLIST 
continually expands and contracts as 
tasks are attached or detached, but 
when the ECBLIST becomes equal to 
zero, i.e. there are no further tasks 
to be attached or detached, control 
returns to the calling program (this 
would normally be the operating 
system). 


4. Sets the CTECB (control task ECB), the 
PECB and theWECB of the major task to 
zero. 
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L( bytes) DEC L(bytes) DEC 
00 


00 
GS ee ee ee eT ar egy te ett eee 1 
72 | | 16 | Task Communications | 
| Standard Save | | Area { 16 
Area | }----------------------~-----} 
| | 72 8 | VDA Control | 
SS eee | | 28 
72 | | }--------------+------------- r 
| 2nd. Save Area/ | LPRV | PRV | 24+ 
| | Workspace | | | LPRV 
| 144 }--~----------------~--------- 
bom nnn ne 4 4 | A(DSA of Attaching {| 28+ 
28 | Task Variable | 172 | Task) | LPRV 
}-—----~--------------------- }---------------------------- 
32 | Event Variable | 204 y | AC(PRVVDA of Attaching | 32+ 
}——--~—--—- -----~-----~----------{ { Task) | LPRV 
1024 | i }---~---~--------+-—---—-------- 4 
| | u | A(Task Variable) | 36+ 
| ECBLIST | | | LPRV 
; | 1228 }------------------~--------- 4 
}---------------------------- | | 
4 | CTECB | 1232 4 | A(Parameter List) |} 40+ 
~----------— ---—---- -- -~--~--| | | LPRV 
5. 16 | Task Communications | }-------------~--------------- 4 
| Area | 1248 | | 
}---------------~-----~-------{ | Copied On-Slots | 
s 8 | VDA Control | | | 
| | 1256 }---------------------------- 4 
}----------—---------------- | 
2. LPRV | : PRV |1256+ | Parameter List | 
| | LPRV | | 
p-——---- nanan errr nn nnn nn nn nner ene nae : 
qu | 0 | LLWS | | 
}---------------------------~ r LWS l 
H.W | 0 | | 
}-—-------------------------- }---------------------------- { 
4 | A (IHEZTASK) [1268+ 16 | | 
i | LPRV | Free Core Control | 
}~—--------------------------] | | 
| | | 1268 L.—----—~—-—-—~~~—-~~--—--------- 4 
3. LLWS | LWS | LPRV+ | | 
| | LLWS | Available Space | 
}----------------------------4 | | 
16 | Free Core }1284+ | | 
| Control | LPRV+ | | 
| | LLWS | | 
ee ee J | | 


Available Space 


SUBTASK 


MAJOR TASK 


e Figure 26. Format of Storage Areas, Save Areas, etc. 
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5. Sets up the APLIST, which is a 
parameter list consisting of a return 
address and a parameter list address, 
to be passed to IHETSAM. 


6. Sets up an ECBLIST of two words 
containing the addresses of the ECB of 
the major task and the PECB of the 
major task. 


7. Attaches the module IHESUB at a 
priority one less than the control 
task. IHESUB then sets up a parameter 
list for IHETSAM and branches to 
IHETSAM (This method circumvents the 
use of the IDENTIFY macro, thus 
enabling the Linkage Loader to be used 
when desired). 


Note: IHETSAM receives control from IHESUB 
which is attached each time a new subtask 
is created (all tasks, including the major 
task, are considered subtasks of the 
control task in this context). Using the 
information stored in register RA, IHETSAM 
initializes the major task, a subtask or a 
message task, according to the values of 
RA: 





a. RA is negative: subtask 
initialized 


b. RA is positive and points to a 
fullword whose bit 0 = 0: major 
task initialized 


c. RA is positive and points to a 
fullword whose bit 0 = 1: message 
task initialized 


8. Waits on the two words in ECBLIST until 
one of them is complete: 


a. if the ECB of the major task has 
been posted, then an error has 
occurred which caused the 
operating system to terminate the 
task: in this case a message is 
put out and the program is 
terminated. 


b. the PECB of the major task has 
been posted. The control task 
determines the action it is to 
take from the code posted. 


CONTROL TASK SUBROUTINES 


Having. passed control to IHETSAM (via 

IHESUB), the control task will go into a 
WAIT state on the two word ECBLIST. This 
wait may be resolved by a code posted in 
four of the thirty bits used for the POST 
CODE of the PECB of a subtask, or by 

termination of the major task. The code 


and the subsequent action to be taken is as 
follows: 


DECIMAL 


1. O (ENQUEUE) Control task is to go into 
a wait state until subtask has 
finished with a soft area of code 


2. 4 (ATTACH) Attach a new subtask 


3. 8 (PRIORITY) Change the priority of a 
specified subtask 


4. 12 (DETACH) Special detach routine for 
message tasks only. 


‘5. 20 STOP has been executed. 


These subroutines operate in the 
following way: 


1. Enqueue Subroutine 


This subroutine simulates an 
ENQUEUE/DEQUEUE by putting the control 
task in a WAIT state so that it is 
unable to service requests from other 
tasks until the subtask which 
requested the enqueue brings the 
control task out of the WAIT state. 
The functions of this subroutine are: 


ae (1) Set a bit ‘ont in the FLAG 
byte of the TCA to indicate 
"“ENQUEUED" 


(2) Set the completion code of the 
WECB of the subtask to allow 
it to continue 


b. Wait on CTECB until posted by 
subtask 


c. Zero the CTECB 
ad. Go back to WAIT on ECBLIST. 
2. Attach Subroutine 
The functions of this subroutine are: 


a. If the TASK or EVENT variables are 
already active, post the WECB of 
the subtask with the appropriate 
error code and go back to wait on 
ECBLIST. 


b. (1) Initialize the TASK and EVENT 
variables. If one or both do 
not exist, issue a GETMAIN 
macro for dummy TASK or EVENT 
variables and set a flag in 
the variables so they can be 
freed when the task is 
detached. 
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3. 
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(2) Determines that there are not 
more than 254 active subtasks: 
if more than 254 active 
subtasks, post error code. 


c. Attach IHESUB with the correct 
priority 


ad. IHESUB passes control to IHETSAM 


e. Wait on a two-word ECBLIST for 
either the task to terminate (due 
to no core bé@ing available) or 
until IHETSAM has completed the 
subtask initialization. The 
Subtask will post back the address 
of its TCA when initialization is 
completed. 


f. Post the WECB of the attachors 
Subtask with code 0 to indicate no 
errors 


g- Go back to wait on ECBLIST. 


Priority Subroutine 


Since all tasks are now subtasks of 
the control task, any task can change 
the priority of any other task. To 
accomplish such a priority change, 
compiled code invokes entry point 
IHETPRA Of module IHETPR. IHETPRA in 
turn requests the control task to 
effect the change via entry point 
IHETPRB. 


Therefore, the functions of this 
subroutine are: 


a. Call IHETPRB to perform the 
priority change (see ‘PRIORITY 
Pseudo-Variable" in this chapter) 


b. Post WECB of the subtask with zero 


c. Go back to wait on the ECBLIST 


a) Detach Subroutine for Non-Message 
Tasks 


A subtask always requests the 
DETACH function of the control 
task when it is enqueued (i.e. 

the control task is waiting on 
CTECB). Therefore, the subtask 
must set a code in the CTECB to 
request the control task to DETACH 
a particular task. The CTECB is 
posted with a completion code 
equal to the address of the TCA of 
the task which is to be detached. 


There are three types of tasks to 
consider: 


(1) The task to be detached is the 
requesting task and APLIST is 


zero (i.e. task did not 
terminate abnormally). In 
this case, the functions of 
the control task are:- 


(a) Remove the A(PECB) of the 
subtask from its ECBLIST 


(b) Detach the TCB of the 
subtask 


(c) Free the TASK and EVENT 
variables if they were 
dummy 


(d) Go and wait on the ECBLIST 


(2) The task to be detached is not 
the requesting task. In this 
case, step (d) above will be 
replaced by:- 


(d) Wait on CTECB again 


The remaining functions are the 
same. 


(3) The task to be detached is the 
requesting task and APLIST is 
non-zero (i.e. task 
abnormally ended). In this 
case, the functions of the 
control task are:- 


(a) Remove A(PECB) of the 
subtask from its ECBLIST 


(b) Issue a GETMAIN macro 
instruction. In this area 
set a flag to indicate to 
IHETSAM that a message 
task is to be initialised 
and to store the 
completion code statement 
number and offset. The 
attached task will link to 
IHETEXC, using the 
provided workspace. 


(c) Detach the TCB of the 
subtask and free dummy 
TASK or EVENT variables. 


(d) Attach IHESUB(IHETSAM) and 
add the address of its 
PECB (which is located in 
the GETMAIN area) to the 
ECBLIST of the control 
task. 


(e) Go and wait on the new 
ECBLIST 


4. b) Detach Subroutine for Message 


Tasks 


This routine detaches the 
requesting message subtask and 
frees the core storage obtained 
for it. It then returns to wait 
on ECBLIST. 





When STOP is posted, the control task 
sets a flag to indicate this and then 
goes to the ENQ subroutine. 


INITIALIZATION OF MAJOR TASK 


When the major task initialization routine, 
IHETSAM, is attached (via the control task 
and IHESUB) it has a priority of one less 
than the control task. This has the effect 
of making the whole program appear to have 
a priority of one less than the operating 
system limit priority, which allows the 
control task to be posted and to assume 
control immediately. 


IHETSAM is similar to the 
non-multitasking initialization routine 
IHESAP (described in Chapter 4), but in 
addition: 


1. A flag bit (bit 8) in the PRV VDA is 
set to indicate that it isa 
multitasking PRV VDA 


2. The address of the task variable is 
placed in the PRV VDA and the other 
task-oriented words of the PRV VDA are 
set to zero (see Appendix K) 


3. A SPIE (Specified Program Interruption 
Exit) macro is issued which names the 
error-handling module, IHEERR, which 


0 | 31 
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0| Flags | A(Task variable) | 


}--------1----------------------------- 


4 | A(Event variable) | 


8| Priority relative to attaching task | 


}-------—-------------—--------------—-- 


12| A(called procedure) { 
aa + | 
16 | For library use | 
| 
20| For library use | 
}---—--------~--—-- —---—~------------ = 


24| Argument list for called procedure | 
| (X'80° in first byte of last entry | 
{| indicates end of list) | 
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Figure 27. Parameter List for IHETSAT 


Flags 


is invoked in case of a program 
interrupt 


4. A STAE (Specify Task Asynchronous 
Exit) macro is also issued which 
specifies IHETSAX as the exit routine, 
and the address of the TCA as the 
address of the STAE parameter list 


5. The pseudo-registers IHEQVDA, IHEQFVD, 
IHEQADC, IHEQCTS, IHEQTCA, IHEQSLA, 
IHEQSFC, and IHEQATV are then 
initialized 


INVOCATION OF SUBTASK 


When a CALL statement with a TASK, EVENT or 
PRIORITY option is executed, compiled code 
calls the library module IHETSAT, which 
requests the control task to attach the 
subtask specified in the CALL statement. 


When the PL/I program includes the TASK 
or EVENT options in a CALL statement, then 
compiled code is generated which, at 
execution time, is used to initialize the 
TASK and EVENT variables. The 
initialization consists of setting TASK and 
EVENT variables inactive, inserting the 
address of the associated symbol table 
entry in the TASK variable and setting the 
STATUS halfword in the EVENT variable to 
zero . Furthermore, compiled code would 
have created an argument list (Figure 27) 
and inserted its address in register RA. 


Pointers to the PRV and DSA of the 
attaching task are stored in the two words 
of the parameter list reserved for library 
use; they are used in chaining tasks in 
*mother-daughter’ relationships: 


If the CALL statement includes a 
PRIORITY option, the sum of the relative 


zero if no TASK option 


zero if no EVENT option 


X'80° if no PRIORITY option 


X'80* if no argument list 
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priority from the parameter list supplied 
by the compiled code and the dispatching 
priority in the task variable of the 
attaching task is stored in the task 
variable of the subtask; if the sum exceeds 
the limit priority for the PL/I program 
(16*JSPRI+10), the dispatching priority for 
the subtask is made equal to the limit. 
(See IBM System/360 Operating System: PL/I 
(F) Programmer's Guide for a discussion of 
priority in a PL/I program). The limit 
priority of the attaching task is also. 
placed in the task variable of the subtask. 
If there is no PRIORITY option, and a task 
variable exists, the dispatching priority 
in the task variable is assumed; if the 
task has a dummy task variable, the 
dispatching priority is the same as that of 
the attaching task at the time the subtask 
is attached. 


INITIALIZATION OF A SUBTASK 


Module IHETSAT is called by compiled code 
when a subtask is to be attached. This 
routine stores the address of the PRV and 
DSA of the attaching task in the parameter 
list, and then stores the address of the 
parameter list in APLIST (in the TCA). 
Having posted the control task to attach a 
subtask, IHETSAT waits until it is informed 
by the control task that the subtask has 
been attached or an error has been found. 
When the WAIT is satisfied, it tests to see 
if any errors were detected. If so, it 
raises the appropriate ERROR condition and 
branches to IHEERRC. If there are no 
errors, it returns normally to compiled 
code. 


On being posted by IHETSAT to attach a 
subtask, the control task executes its 
attach subroutine which calls IHESUB. The 
subtask initialization routine, IHETSAM, 
receives control from IHESUB, which is 
attached each time a new subtask is 
created. At this time, register RA 
contains the complement of the address of 
the parameter list prepared by compiled 
code (Figure 27). This conforms to the 
previous discussion on the control task 
wherein it was stated "RA is negative; 
subtask initialized". 


IHETSAM calculates the length of the PRV 
VDA and LWS required by the subtask and 
issues a GETMAIN macro instruction for the 
amount of storage needed (rounded up to a 
multiple of 2048 bytes): 


Then it initializes the PRV VDA as 
follows: 
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1. It copies the contents of the PRV of 
the attaching task into the PRV of the 
new subtask 


2. It initializes the pseudo-registers 
IHEQTCA, IHEQSLA and IHEDATV, and 
zeroes IHEQRTC, IHEQEVT, and IHEQFOP 


3. It copies any ON-fields in the DSA of 
the attaching task, and the procedure 
argument list (if one is being 
passed), into the PRV VDA of the new 
subtask. 


G. It increments the pseudo-register 
IHEQTIC by one. (IHETSAM sets IHEQTIC 
to zero when it initializes the major 
task. Each time a new subtask is 
attached, IHETSAM adds one to the 
count in IHEQTIC; the count thus 
indicates the level of each task 
within the hierarchy) 


5. It issues a SPIE macro for IHEERRA 
6. It issues a STAE macro for IHETSAX. 


The control task is then posted to 
indicate the completion of the 
initialization routine and IHETSAM then 
branches to the address of the called 
procedure. 


MESSAGE TASK 


In the case of a message task being 
required, IHETSAM sets up register 1 to 
contain the address of the parameter list 
and then links to IHETEXB to put out a 
message. IHETSAM then asks to be detached 
by posting the control task and waits until 
detached. 


EXIT AND TERMINATION OF TASKS 
NORMAL TERMINATION OF A TASK 


A PL/I task can be terminated by the 
execution of any one of the statements END, 
RETURN, STOP and EXIT. 


The action taken by the library END, 
(IHETSAE) and RETURN (IHETSAR) routines is 
Similar to that of the GO TO routine 
(IHETSAG); the action differs from that of 
the non-multitasking equivalents in that 
any tasks attached in the block being 
terminated must also be terminated. This 
termination is done by means of the CTECB 
DETACH routine (see ‘Control Task 
Subroutines'). If the block to be 


terminated is also the end of a procedure 
called with the TASK option, the control 
task is informed and the task is detached. 


If it is the end of the major task, the 
FINISH condition is raised and the program 
branches to the error-handling routine. 

The END or RETURN routine will, on 
completion, post the control task to detach 
the major task. Finally, when the ECBLIST 
has no entries left, control is returned to 
the calling program. 


The abnormal-end-of-task routine 
(IHETSAZ) is entered 


1. From IHEERR when return is made from 
the error routine in a subtask or from 
the FINISH routine in the major task. 


2. When an EXIT statement is executed in 
any task, or 


3. When CALL IHEDUMT is executed in any 
task. 


IHETSAZ detaches the task, and any tasks 
that it has attached, in the manner 
described under ‘GO TO Statements’. 


The end-of-program routine IHETSAY is 
entered when a STOP or CALL IHEDUMP 
Statement is executed in any task. IHETSAY 
terminates all subtasks in the manner 
described under ‘GO TO Statements’. In 
both cases, control passes back to the 
calling program, by way of the control 
task, at completion. 


ABNORMAL END-OF-TASK EXIT ROUTINE 


If a task terminates abnormally, the STAE 
exit routine (IHETSAX) is called. IHETSAX 
is specified in the STAE macro and is 
invoked whenever a subtask is attached. 

The STAE exit routine firstly detaches all 
subtasks of the abnormally terminating task 
and then informs the control task of the 
condition of that subtask. An area of 
storage is obtained by the control task in 
which the name of the subtask and the 
completion code are stored. This storage 
area also contains space for a save area to 
be used by the message task. The control 
task detaches the terminating task and 
attaches a task which prints out a message 
(as described under ‘Control Task 
Subroutines") giving the name, if any, of 
the subtask, the operating system 
completion code, and, in the more common 
cases, an indication of the probable error. 
The message is put out on SYSPRINT if it is 
open, otherwise it is put out on the 
console. 


To obtain the name of the subtask for 
insertion in the message, IHETSAX locates 
the task variable of the subtask by 
initiating a save-area trace from the PRV 
of the current task. The address of the 
TCA of the abnormally terminating task is 
passed in a parameter list to the STAE exit 
routine along with the completion code. 


GO TO STATEMENTS 


The multitasking housekeeping routine for 
GO TO Statements (IHETSAG) differs from its 
non-multitasking equivalent only in that if 
control is transferred outside the block in 
which the statement occurs, any tasks that 
are attached in the blocks that are freed 
must be terminated. If any tasks have been 
attached in the block, the task variable 
chain pointer in the DSA will point to the 
task variable of the most recently created 
subtask. IHETSAG searches the chain 
through each DSA in each task until a task 
is found that has attached no subtasks; 
this task is then terminated by informing 
the control task that this task is to be 
detached. 


The process is repeated until all the 
tasks attached in the block, and their 
descendants, have been terminated. In the 
process, all storage associated with these 
tasks is returned to the supervisor, and 
all files opened in the tasks are closed. 


ON-UNITS AND ENTRY PARAMETER PROCEDURES 


The multitasking routine IHETSAN modifies a 
recursive environment when an on-unit or an 
entry parameter procedure is entered or 
ended. It differs from the 
non-multitasking routine (IHESARA) in two 
respects. | 


1. the chain of recursive DSAs is 
followed back to the PRV of the major 
task, and 


2. if a CALL statement calls an entry 
parameter procedure with a task 
option, the address of the entry 
parameter is placed at the top of the 
parameter list, the address of IHETSAT 
is assigned to the entry parameter, 
and IHETSAN is called. When IHETSAN 
terminates, it points register RA at 
the IHETSAT parameter list and 
branches to IHETSAT. 
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CONTROLLED STORAGE 


The allocation and freeing of storage for 
controlled variables in a multitasking 
environment is handled by library module 
IHETCV. This module is independent of 
IHETSA and is loaded only if the CONTROLLED 
attribute is used. When storage is 
allocated, the task invocation count from 
pseudo-register IHEQTIC is stored in the 
first halfword of the controlled variable. 
Before a controlled variable is freed, its 
task invocation count is checked; if it 
does not correspond with the value in 
IHECTIC for the task in which the statement 
occurs, the variable is not freed. 
Controlled storage is allocated in subpool 
0 if it is in the major task, and in 
subpool 1 if it is in a subtask. 


MULTITASKING PSEUDO-VARIABLES AND BUILT-IN 
FUNCTIONS 


Statements in which the STATUS 
pseudo-variable appears, or which contain 
the COMPLETION or STATUS built-in function, 
are executed from compiled code without a 
library call. 


COMPLETION PSEUDO-VARIABLE 


On execution of an assignment statement in 
which the COMPLETION pseudo-variable 
appears, the expression on the right-hand 
side is evaluated and converted to a 
bit-string of length 1, which is then 
stored at bit 24 of a fullword. Compiled 
code then calls IHETEVA, passing the 
address of the event variable named in the 
pseudo-variable, and that of the fullword 
(in a list pointed to by register RA). If 
the event variable is active, the ERROR 
condition is raised - otherwise IHETEVA 
takes the following action: 


1. It informs (POSTS) the control task it 
wishes to execute soft code and then 
waits until the request is satisfied. 


2. It sets the I/O flag in the event 
variable (bit 1 of the flag byte) to 
zero. 


3. (a) If the bit string = ‘'0‘'B, it sets 
bit 1 (the ‘complete’ bit) of the 
ECB in the event variable to zero. 


(b) If the bit string = '1'B, it tests 
to see whether the event is 
already complete. If not complete 
it posts the ECB with a completion 
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code of zero. If it is complete, 
IHETEVA does nothing. 


4. It informs the control task it has 
finished executing soft code(Code = 0) 


PRIORITY PSEUDO-VARIABLE 


The PRIORITY pseudo-variable is used to set 
the dispatching priority of a task to a new 
value relative to that of the current task. 
On execution of an assignment statement in 
which the PRIORITY pseudo-variable appears, 
the expression on the right-hand side is 
evaluated and converted to a fixed-point 
binary constant of default precision, which 
is assigned to a fullword. Compiled code 
then calls IHETPRA, passing the address of 
the task variable of the task named in the 
pseudo-variable and that of the fullword 
(in a list pointed to by register RA). If 
the pseudo-variable does not specify a 
task, the current task is assumed. IHETPRA 
requests the control task to change the 
priority of a task by posting a code of 08 
in the PECB of the specified subtask. The 
control task branches to IHETPRB which uses 
the dispatching priority of the task 
variable to compute the new priority. 
IHETPRB then stores the new priority value 
in the task variable; if the task variable 
is already active, it issues a CHAP (change 
priority) macro to change the priority of 
the associated task. It then assigns to 
the task variable the new value of the 
dispatching priority, calculated as 
follows: 


New dispatching priority of named task 
= MAX (0,MIN (limit-1,P+N) ) 


where P = dispatching priority of 
current task and N = increment 


NOTE: Under this system of changing 
priorities, any task can change the 
priority of any other task. 


PRIORITY BUILT-IN FUNCTION 


The PRIORITY built-in function yields the 
dispatching priority of a task relative to 
that of the current task. On execution of 
a statement in which the function appears, 
compiled code calls IHETPBA, passing the 
address of the task variable of the task 
named in the function and the address of a 
fullword target field (in a list pointed to 
by register RA). IHETPBA subtracts the 
dispatching priority of the current task 
from that of the named task, and assiaqns 
the difference to the target field. The 


dispatching priorities are obtained from 
the respective task variables. 


THE WAIT STATEMENT 


When a WAIT statement is executed ina 
multitasking environment, compiled code 
calls the library module IHETSW, passing 
the addresses of the event variables 
associated with the statement. IHETSW 
first places itself in any queue that may 
exist via control task subroutine ENQ so 
that the control task may decide when 
IHETSW may safely access "soft code”. 


It then scans the event variables to see 
whether enough events to satisfy the WAIT 
statement are complete with regard to the 
PL/I program (‘complete bit, ECMP, set to 
1). If not, IHETSW scans the ECBs for the 
I/O events, and in each case where the I/0 
event is complete sets the check bit (EMCH) 
in the corresponding event variable to ‘1. 
A list is then made of all the incomplete 
I/O and multitasking events. 


If the number of PL/I and I/O complete 
events is sufficient to satisfy the WAIT 
statements, the relevant I/O transmit 
modules are invoked to complete the I/0 
events. (See "General Logic and Flow’ 
under ‘*Record-Oriented I/O" in Chapter 3.) 
If there are no multitasking events in the 
list, and if the number of completed 1/0 
events is not sufficient and all the I/0 
events must be completed to satisfy the 
WAIT statement, the check bit in each event 
variable is set to 1 and the relevant I/0 
transmit module is invoked. If not all the 
I/O events need to be waited on, or if 
there are some multitasking events in the 
list, a multiple WAIT instruction is issued 
for the list of incomplete events. When 
the macro has been satisfied, if the list 


included any I/O events, the corresponding 
ECBs are scanned and the check bits in the 
event variables corresponding to completed 
ECBs set to 1; the I/O transmit module is 
then invoked. 


The I/O event variables that are checked 
by the transmit modules are set complete 
and the check bits are set to zero. The 
event variables are then set inactive and 
removed from the task and file chains. 
IHETSW then dequeues from the control task 
by posting the CTECB with a completion code 
of zero. 


ALTERNATIVE I/O MODULES FOR MULTITASKING 
PROGRAMS 


Alternative multitasking and 
non-multitasking modules for input/output 
Operations have been created in order to 
prevent the non-multitasking user from 
being inflicted with any multitaskiing 


overheads. These modules are: 
Non-multitasking Multitasking 
IHEOCL IHEOCT 
IHECLT IHECTT 
IHEPRT ITHEPTT 
IHEIOB IHEIBT 
IHEDDO LHEDDT 
IHEION IHEINT 


The entry points for the multitasking 
modules correspond with the entry points of 
the non-multitasking modules. Modules 
which have no alternative form will call 
the correct module by extracting its 
address from the list addressed by 
pseudo-register IHEQADC. This list is 
assembled into IHESAP or IHETSA, whichever 
is present. 
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CHAPTER 6: ERROR AND INTERRUPT HANDLING 


The PL/I Library handles two types of 
conditions at object time which cause 
interruption to the main flow of a program. 
These are: 


1. Conditions for which it is possible to 
specify an on-unit: 


a. Computational program interrupts. 


b. Other conditions. 


2. Execution error conditions not covered 
by a PL/I-defined condition. 


If any of these conditions occurs, 
control is passed to the library error 
handling module IHEERR. (See Figure 29.) 
This module is always resident; if it is 
necessary to print a message at execution 
time, IHEERR links to a group of modules 
normally non-resident but brought into 
storage when required. These are: 


IHEESM: This loads one of the message 
modules and prints the 
appropriate message. 

IHEERD: Data processing error messages. 

IHEERE: Error messages other than those 
in the other error message 
modules. 

IHEERTI: Input/output error messages. 

IHEERO: Error messages for non-I/O ON 
conditions. 

IHEERP: Error messages for I/O ON 
conditions. 

IHEERT: ~-Multitasking error messages. 


The error messages and their associated 
ONCODES are described in IBM System/360 


Operating System: PL/I (F) Programmer's 
Guide. 


All the PL/I-specified ON conditions 
except I/O SIZE and I/O CONVERSION are 
raised by compiled code to facilitate 
reference by the error-handling 
subroutines. Each ON condition has a code 
number (internal to the library) consisting 
of two hexadecimal digits. When an ON 
condition is raised, the code associated 
with it is placed in the error-handling 
pseudo-register IHEQERR. 
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There is an error message for each ON 
condition. In some cases the condition 
(e.g., CONVERSION) may have a group of 
errors associated with it and has therefore 
a group of messages. A complete list of 
the internal error codes and their 
associated messages is given in Appendix E. 


PROGRAM INTERRUPTS 


Fifteen possible program interrupts can 
occur in System/360. Seven of these are, 
Or may be, related to computational 
conditions in PL/I (see Figure 28); 
Oon-units may be specified for these 
conditions. Seven of the remaining eight 
are treated as errors of a non-ON type; the 
eighth one, significance is not handled. 


peaeen Saat See ae 
| Program Interrupts 


a 
| 

}------------------------ }---------------- 
| Fixed-point overflow | FIXEDOVERFLOW | 
| Fixed-point divide | ZERODIVIDE | 
| Decimal overflow | FIXEDOVERFLOW | 
| Decimal divide | ZERODIVIDE | 
| Exponent overflow | OVERFLOW | 
| Exponent underflow | UNDERFLOW | 
{| Floating-point divide | ZERODIVIDE | 
loiweee conc o oalee Se ts aoe rah as J 
Figure 28. Program Interrupts and PL/I 


Conditions 


Because the user may specify on-units 
for handling certain PL/I conditions, when 
an interrupt occurs the PL/I program must 
gain control to see if there is an on-unit 
associated with that particular interrupt. 
This is achieved by the GET PRV subroutine 
in the IHESA module, which issues a SPIE 
macro to: 


1. Provide a program interrupt control 
area (PICA). This is a six-byte area 
(in IHESA) which contains the address 
to which control is passed when an 
interrupt occurs, and information on 
the type of interrupt handled by 
IHEERR. 


2. Cause the supervisor to create a 
program interrupt element (PIE). This 
is a 32-byte area which contains the 
PICA address and also a save area for 
the old PSW and registers 14 to 2 when 
an interrupt occurs. 


IHEERRA 


PROGRAM 
INTERRUPTS 








SAVE ENVIRONMENT 
(STIMULATES 
ANOLING 
COMPLETE : SET 
RESULTS iF 
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Figure 29. 
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Flow through the Error Handling Routine (IHEERR) 
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034 78 31 
"ee TARE amie gaa i a 
| {| PM | A(Exit subroutine) | 
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3200 ny, 
aa crate | 
| Interrupt Mask | 
Ceeeeeeee scotia J 
Figure 30. Format of the Program Interrupt 


Control Area (PICA) 
Definitions of PICA fields: 


PM: Program mask 

A(Exit subroutine): Address of the entry 
point in IHEERR to which control is to 
be passed when one of the specified 
interrupts occurs. This entry point 
is IHEERRA. 


Interrupt mask: Indicates to the supervisor 
which interrupts are to be handled by 


IHEERR. These interrupts are all the 
fifteen possible ones except 
Significance. 
0 7 8 31 
(See a oS eS eee ee 


r | A(PICA) 


}--------1------------------------------- 


l OPSW(Bits 0-31) | 


}----------------------------------------- 


OPSW(Bits 32-63) | 


| Register 14 | 


}-----------------------------------------} 


| Register 15 | 


i Register 0 | 
pom ann en nnn nnn nnn nnn nnn nnn f 
{ Register 1 | | 
pone nnn nnn nn nnn nn men 
| Register 2 | 
a a eee 
Figure 31. Format of the Program Interrupt 
Element (PIE) 


Definitions of PIE fields: 


A(PICA): Address of PICA, for supervisor 
use 


OPSWs Contents of the old program status 
word 


Registers 14 to 2: Contents of these 
registers when an interrupt 
occurs 


On entry to IHEERRA, register RA 
contains the address of PIE. 


It is possible for another program 


interrupt to occur before user corrective 
action has been completed. IHEERR has to 
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guard against this eventuality when it 
obtains control, otherwise the second 
interrupt would cause the supervisor to 
terminate the task. fo avoid this, the 
following method is used: 


1. The PSW in PIE 
in the LWE 
works pace. 


(the old PSW) is saved 
+ x ‘70° area in library 


2. Bits 40 to 63 of the PSW in PIE are 
changed to contain the address of the 
appropriate entry point in IHEERR; 
control is returned to the supervisor. 


3. The supervisor assumes the interrupt 
has been handled satisfactorily and 
transfers control to the new address 
in the PSW in PIE; thus it enters 
module IHEERR again. 


Floating-point registers are saved in 


the library communication area, and the old 


PSW is inspected to find the cause of the 
interrupt. 


If a fixed-point or decimal overflow 
interrupt is forced to occur, the SIZE 
condition may be raised. Therefore when 
one of these interrupts occurs, the 
pseudo-register IHEQERR must be inspected 
to see if the SIZE code has been set. 
Similarly, if any of the divide interrupts 
occurs, IHEQERR must be inspected to see if 
the ZERODIVIDE code has been set. If it 
has, the condition is disabled and control 
returns to the point of interrupt. 


Certain very unusual circumstances may 
result in a program interrupt occurring 
during the execution of IHEERR or of one of 
the library modules called, or linked to, 
from it. For example, if the program 
destroys the PRV, or the DSA chain, or 
parts of library workspace, then it is 
likely that sooner or later a specification 
or addressing interrupt will occur. 


Under these circumstances, the 
programmer or systems engineer requires a 
dump at the earliest opportunity. To 
achieve this, and to prevent any attempt to 
re-enter IHEERRA on account of the second 
interrupt, a SPIE macro is issued every 
time IHEERR is entered. This macro 
provides that, in the event of an interrupt 
occurring, IHEERR shall be entered at entry 
point IHEERRE. Similarly, another SPIE 
macro is issued at each exit point, to 
restore IHEERRA as the normal entry point 
for program interrupts during the execution 
of compiled code and library routines. 


When IHEERRE is entered, a message is 
printed on the console and the program is 
abnormally terminated, with a dump. 


c= 2=Ss== aaa a 5 alasie naire a Dees To ee 
! | | Condition| | 
| Type | Condition |Prefixes | Default | 
| | |permitted|situation| 
}--~----}-----~------- ---------}--------- 
i |CONVERSION | | | 
| | FEXEDOVERFLOW | { All| 
| Comput- | OVERFLOW | Yes | enabled | 
|] ational | SIZE | | except | 
| | UNDERFLOW | SIZE | 
{ | ZERODIVIDE | | | 
}------- $-—---~------- }--------- }--------- { 
j List | AREA | No | Always | 
| pro- | | {| enabled | 
| cessing| | | 
}-------4}-------------}---------}---------4 
| | ENDFILE | | | 
| | PENDING | | | 
| | ENDPAGE { | | 
[Input/ | KEY | | Always | 
{Output | NAME | No | enabled | 
| | RECORD | | | 
| | TRANSMIT { l 
| UNDEFINEDFILE | 
}------- }------------- $--------- }--------- { 
| Program| CHECK | | | 
| check- |SUBSCRIPT- | Yes | Disabled | 
jout | RANGE { | | 
| STRINGRANGE | { | 
}-------}-------------}---------}---------] 
|Prog- |CONDITION | | Always | 
| rammer- | | No | enabled | 
[named | | | 
t------- }+------------- }~--------- +--------- { 
[System | ERROR | No | Always | 
action | FINISH | | enabled | 


| 
a feta aaa en enn Sra ae pacar ener eee OE Sere a 
Figure 32. PL/I ON Conditions 


ON CONDITIONS 


The six classes of ON conditions defined in 
PL/I are shown in Figure 32. To deal 
Satisfactorily with the situation when any 
of these conditions arise, IHEERR must: 


1. Recognize the condition. 
2. See if it is enabled. 


3. If so, see if there is an on-unit for 
the condition. 


4%. If there is an on-unit, transfer 
control to IHESARA, which, after doing 
the necessary housekeeping, will 
transfer control to the on-unit. 


5. If no on-unit, take system action for 
the condition. 


6. Return to the interrupted program or 
terminate, according to the provisions 
of the PL/I language. 


In order to carry out these operations 
IHEERR needs: 


1. Information passed when the error 
condition arises. 


2. Information set by compiled code in 
the DSA for each procedure. A 
two-word ON field is allocated in the 
DSA for this purpose. (See Chapter 
4.) 


Action taken by compiled code in 
preparation for the possibility of a 
condition arising during execution is 
summarized here. 


Prologue: The prologue allocates space in 
the DSA for: 


1. Every ON statement in the block. 


2. Each ON condition disabled in the 
block. 


ON CHECK (identifier 1,......identifier n) 
is interpreted as n ON statements. 


For each of the occurrences given above, 
the prologue stores information in the two 
words in the DSA ON field: 


ist word: Contains the error code for the 
condition and the address of data 
identifying the condition. This word 
is called the search word comparator. 
(See Figure 33.) 


T 
Type of ON | 


| 

{ condition -}------ [roo no 
| {Byte 1] Bytes 2 to 4 | 
}----------~------ }------ }----------------- 
| I/O | | A (DCLCB) { 
| CONDITION | {| A (CSECT) | 
oon - - - - {Error }----------------- 


{ 
| CHECK (label) | {A (Symbol name & | 


| |code | length) 
|CHECK (variable) | [A (Symbol table) | 
~~--~~----------| }----------------- { 
| Others | {| Nothing stored | 
bose eee eee [een en Lecwereowece ees J 
Figure 33. Format of the Search Word 
Comparator 


2nd Word: Byte 1: Bits 0, 1 and 4 are set 


as follows: 


Bit 0 0 Not the last ON field in the 


DSA 


1 Last ON field in the DSA 
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Bit 1 1 Condition disabled 


Bit 4 = 1 Dummy ON field 


In the second word, either bit 1 or bit 4 
is set to 1. (See ‘Prefix Options’, 
below.) 


ON Statement: When the ON statement is 
executed, compiled code stores information 
in the second word of the ON field: 


Byte 1: 
Bit 2 = 0 SNAP not required 
= 1 SNAP required 
Bit 3 = 0 Normal 
= 1 System action required 
Bit 4 = 0 No longer dummy 
Bytes 2-4: A(on-unit) 


Prefix options: An ON field for an ON 
condition must be created by the prologue 
whenever: 


1. An ON statement is present in the 
block. 


2. An ON condition becomes disabled at 
any time during the execution of the 
block. 


3. CHECK is enabled within the block. 


This ON field is always set to dummy by the 
prologue. It is also set to disabled if: 


1. The condition is disabled by a prefix 
option in the block-header statement. 


2. The condition is disabled by default 
and there is no enabling prefix option 
in the block-header statement, or 
within the block. The exceptions to 
this are CHECK, SIZE, STRINGRANGE, and 
SUBSCRIPTRANGE, which are dealt with 
as follows: 


CHECK: No ON fields are created if 
this condition is disabled by 
default 


SIZE, STRINGRANGE, and SUBSCRIPTRANGE: 
If these conditions are disabled 
by default, flags are set in the 
flag byte of the DSA as follows: 


SIZE: bit 7 = 0 
STRINGRANGE bit 2 = 0 
SUBSCRIPTRANGE: bit 4 = 0 


Execution of an ON statement in the block 
causes removal of the dummy flag and 
insertion of the flags indicating the 
action required. It does not remove the 
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disable flag if on. Execution of a REVERT 
statement causes reinstatement of the dummy 
flag. 


During execution of the block, statements 
may be executed which have disabling prefix 
Options in them. Compiled code must be 
inserted before and after the statements 
tos 


1. Set the disable flag before the 
statement. 


2. Restore the original flags after the 
statement. 


Similarly, to enable prefix options, 
compiled code must: 


1. Set the disable flag off before the 
statement. 


2. Restore the original flags after the 
statement. 


Prefix options specified on outer blocks 
carry down into internal blocks. The 
implementation of these blocks should be as 
if the option had been explicit in each of 
them. 


Action by the Library 


When an ON condition arises during 
execution, IHEERR gains control from one of 
the following: 


1. The supervisor 
2. Compiled code 


3. Another library module 


In case 1, the ON condition code 
required is determined by inspection of the 
program interrupt code in the old PSW. For 
cases 2 and 3, the ON condition code is 
passed in pseudo-register IHEQERR, except 
for the CHECK and CONDITION conditions, 
when a parameter list is used. From this 
code and information passed in the calling 
sequence, a search word is generated in 
library workspace in all three cases; the 
format of the search word is identical with 
that of the search word comparator 
(Figure 33). 


When the search word has been created, 
IHEERR initiates a search through the chain 
of DSAs to determine the action to be 
taken. Each DSA is analyzed in turn, from 
the end of the chain upwards towards the 
beginning. The search proceeds as follows: 


Bit 6 of the flag byte of the first 
available DSA is tested to see if that 
DSA contains any ON fields. Then: 

a. No ON fields: If the DSA is the 
current DSA and the condition is 
SIZE, STRINGRANGE, or 
SUBSCRIPTRANGE, the flag byte of 
this DSA is examined to see if the 
condition is disabled: 


Disabled: the program returns to 
the point of interrupt. 


Not disabled: The DSA is ignored. 


If the condition is CHECK, the 
program returns to the point of 
interrupt. 


ON fields: The first word of each 
ON field - the search word 
comparator ~ 1S compared with the 
search word to see if a match is 
found. If a match is found, the 
second word of the ON field in the 
DSA is tested to see what action is 
required. 


If the last ON field is reached before 
finding a match, then: 


If the DSA is the current DSA and 
the condition is SIZE, STRINGRANGE, 
or SUBSCRIPTRANGE, the 
corresponding flags in the DSA are 
tested. 


ae 


b. The error code is tested to see if 


the condition is CHECK. 


This may result in a return to the point 
of interrupt. If not, the next DSA is 
obtained and analyzed in the same way. 


If a match has been found, then the 
following tests are made: 

1. Is the condition disabled by a prefix 
option? (This test can only be 
applied when the matching ON field is 
contained in the current DSA.) 


Disabled: No further processing 
in IHEERR; the program returns to 
the point of interrupt. 

Not disabled: Next test is made. 


Is the matching ON field a dummy ON 
field? 


The field is 
next DSA is 


Dummy ON field: 
ignored and the 
obtained. 


No dummy ON field: Next test is 
made. 
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Is SNAP action required? 
SNAP action required: A summary 
flow trace is written on the 
system output file. This output 
contains the ON-condition 
abbreviation and trace~back 
information identifying the 
procedures in the chain. The 
statement number may optionally 
be included. Each procedure is 
identified by chaining back 
through the DSA chain until a 
procedure DSA is found and then 
uSing the contents of register BR 
in the appropriate save area. 
The search ends when the 
chain-back reaches the external 
save area. An example of this 
output is given in IBM System/360 
Operating System: PL/I (F) 
Programmer's suide. 


SNAP action not required: Proceed 
normally. 


In a multitasking program, when the 
search word has been created, IHEERR calls 
IHETER, which searches the ON fields of the 
DSA in a similar manner to IHEERR. In the 
absence of a matching ON field, the search 
continues until the PRV VDA of the major 
task is reached. If a subtask PRV VDA is 
encountered during the search, any ON 
fields that have been copied into it from 
the DSA of the attaching task are also 
checked. If a match is not found, the 
search continues through the DSAs of the 
attaching task. 


System Action 


System action means writing a message and 
then either continuing or raising the ERROR 
condition. It is performed if: 

1. the system action flag is set in the 
matching ON field, or 
2. no matching ON field can be found in 
the DSA chain. 


If a match is found, and an on-unit 
address is given, then, to guard against 
the possibility of recursive use when 
control returns from the on-unit by means 
of a GO TO statement, a new block of 
library workspace is obtained. This LWS is 
added to the DSA chain as described in 
"PL/I Object Program Management’. In order 
to pass control to the on-unit, the 
recursion subroutine in IHESAP is called; 
this establishes the correct environment 
and then branches to the on-unit. Return 
from the on-unit may be made in one of two 
ways: 
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1. On normal completion, control passes 
to IHEERR, which returns to compiled 
code at the point following the 
instruction which caused the condition 
to be raised. 


2. Execution of a GO TO statement. In 
this case the GO TO subroutine 
(IHESAFC or IHETSAG) is entered to 
carry out the housekeeping described 
in Chapters 4 and 5. 


STANDARD SYSTEM ACTION AND CONDITIONS OTHER 
THAN ON CONDITIONS 


If an ON condition is raised and there is 
no matching ON field for the condition, 
standard system action is taken. This 
action is defined by the PL/I language. 
Another set of error conditions can arise 
at object time for which no specific ON 
condition is defined in the language (e.g., 
logarithm of a negative number). In these 
cases, implementation-defined system action 
is taken. 


An error message is printed when 
PL/I-defined or implementation-defined 
system action occurs. Then, depending on 
the severity of the condition, either 
processing continues or the ERROR condition 
is raised. In a non-multitasking program, 
or in a major task, raising the ERROR 
condition generally leads to the FINISH 
condition being raised and then to the 
abnormal termination of the job step by the 
ABEND macro. The exceptions to this are 
when there is a GO TO statement in the 
ERROR or FINISH unit. Ina multitasking 
program, if the ERROR condition is raised 
in a subtask, instead of the FINISH 
condition being raised, IHETSAZ is invoked. 
(See ‘Termination Of a Task’ in Chapter 5.) 
A complete list of object-time error 
messages, with details of the conditions 
that cause them to be issued, is given in 
IBM System/360 Operating System: PL/I (F) 
Programmer's Guide. 


When the printing of an error message is 
required, the appropriate modules of the 
non-resident part of the error package are 
dynamically loaded into storage. The seven 
modules concerned are: 


IHEERD, IHEERE, IHEERI, IHEERO, IHEERP, 
IHEERT: The error message modules; 
they contain the error message texts 
together with tables to locate the 
messages. Only the module containing 
the required message is loaded. 


IHEESM: Contains the code required to 


print SNAP and system action messages. 
This module is always required. 
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An action indicator is obtained during the 
process to determine whether normal 
processing should continue if the ERROR 
condition is raised. The appropriate 
action is taken when the message has been 
printed as output. 


BUILT-IN FUNCTIONS 


The two built-in functions, ONLOC and 
ONCODE, may only be used in an on-unit; 
they provide environmental information 
associated with the raising of the latest 
ON condition. 


ONLOC 


An interrupt can occur that can cause entry 
to the on-unit in which ONLOC is specified. 
If this happens, the ONLOC built-in 
function identifies the BCD name of the 
entry point of the procedure in which the 
interrupt occurs. 


The address of this BCD name is computed 
by chaining back through the DSA chain 
until the first procedure DSA is reached 
and by using the contents of BR in the 
appropriate save area. The length of this 
name and the maximum length are found; 
these two lengths and the pointer to the 
BCD name are inserted in the target SDV 
whose address has been passed to ONLOC as a 
parameter. 


If ONLOC is specified outside an 


on-unit, a null string is inserted in the 
target SDV. 


ONCODE 


The ONCODE built-in function picks up a 
value from the WONC field in the library 


communication area in LWS previously set by 


IHEERR. This value is implementation- 
defined by the type of error that caused 
the interruption. It may be specified in 
any On-unit. If specified in an ERROR or 
FINISH unit, the ONCODE will be that of the 
error or condition that caused the ERROR or 
FINISH unit to be entered. 


If ONCODE is specified outside an 
on-unit, a unique ONCODE value (0) is 
returned. A list of ONCODEs and an 
explanation of their use are given in IBM 


System/360 Operating System: PL/I(F) 
Programmer's Guide. 


MODEL 91 AND MODEL 195 INTERRUPT HANDLING 


Program interrupts occurring in code 
executed on an IBM System/360 Model 91 or 
Model 195 require different treatment from 
that described above. This is necessary 
because Models 91 and 195 are capable of 
executing several instructions 
concurrently: hence a situation may arise 
in which several program exceptions may 
occur before an interrupt is raised. 


As soon as a single exception occurs, 
Models 91 and 195 ensure that execution of 
the instructions already decoded is 
completed, and then raise an interrupt. 
During execution of these instructions, 
further exceptions may occur. If there are 
no more instructions to be executed at the 
time an exception occurred, then the 
interrupt raised is known as a precise 
interrupt; the PSW contains the address of 
the instruction following that in which the 
exception occurred. 


If, however, further instructions were 
executed, then the interrupt is known as an 
imprecise interrupt; the PSW at 
interrupt-time contains the address of the 
next instruction to be executed, but this 
is not necessarily the address of the 
instruction following any of the exceptions 
raised. The instructions causing the 
exceptions cannot therefore be identified. 
If there is more than one exception prior 
to interrupt, then a multiple-exception 
imprecise interrupt is said to have 
occurred. Full details of Model 91 and 
Model 195 operation and interrupt handling 


are given in IBM System/360 Model 91, 
Functional Characteristics, Form A22-6907, 


and IBM System/360 Model 195, Functional 
Characteristics, Form A22-6943. 


When an imprecise interrupt is raised, 
therefore, Models 91 and 195 indicate the 
situation by setting the interruption code 
and the interruption length code in the PSW 
as follows: 


1. Recognition that an imprecise 
interrupt has occurred: Bits 26-33 are 
set to zero for Model 91 and bits 
28-33 are set to zero for Model 195. 


2. Identification of the type or types of 
exception in the interrupt: For Model 
91 bits 16-25, and for Model 195 bits 
16-27 excluding bit 18 are set as 


follows: 
Bit Type of Exception 
16 Model Protection 
17 195 Addressing 
18 Specification 
19 Data 

20 Fixed-point overflow 
21 ?>Model \Model Fixed-point divide 
22 91 195 Exponent overflow 
23 Exponent underflow 
24 Significance , 
25 | Floating-point divide 
26 Decimal overflow 
27 Decimal divide 


Implementation 


The Library module IHEM91 handles the 
problems associated with imprecise 
interrupts on Models 91 and 195. This 
module is obtained by the user specifying 
the OBJIN option as a parameter in the EXEC 
statement; this creates an ESD entry that 
results in IHEM91 being linkage-edited with 
the Library error and interrupt module 
IHEERR. 


Initially, IHEERR tests bits 28-31 of 
the PSW to determine if these bits are all 
zero (i.e., if an imprecise interrupt 
exists) : | 


1. All zero: Imprecise interrupt; control 
is passed to IHEM91 


2. Any bit non-zero: No imprecise 
interrupt; IHEERR handles the 
Situation in the normal way 


On receiving control, IHEM91 tests bits 
16-27 excluding bit 24 to determine which 
exceptions have occurred. All bits (except 
Significance) are tested, as more than one 
type of exception can occur in an imprecise 
interrupt. If the bit tested is on 
(non-zero), then: 


1. Condition list: IHEM91 sets an entry 
in a list of PL/I conditions and 
program exceptions. The list is 
stored in the LWE area of Library 
workspace (LWS); an entry indicates 
that the particular condition or 
exception must be raised. The list 
consists of from one to eight entries, 
processed in the order: 
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UNDERFLOW 
FIXEDOVERFLOW or SIZE 
OVERFLOW 

ZERODIVIDE 

Data exception 
Specification exception 
Addressing exception 
Protection exception 


Note: ZERODIVIDE is entered only once 
in the list, even if 
floating-point divide and 
fixed-point divide both occur. 
ZERODIVIDE will: be raised on 
Model 195 if decimal divide 
occurs. dence three exceptions 
may result in one ZERODIVIDE on 

Model 195. Significance is not 
handled, as it is disabled in 
all PL/I programs. 
FIXEDOVERFLOW and SIZE cannot 
both be raised since they are 
raised by the same hardware 
condition. 
raised by fixed-point overflow 
and decimal overflow on Model 
195. 





2. Interrupt count: The value in the 


ONCOUNT field (WONC + 4) in the LCA is 


incremented by 1. Thus the total 
value in this field is the total 
number of conditions or exceptions to 
be raised. When a multiple-exception 
imprecise interrupt does not exist 
(because there are no exceptions or 
only a single exception) the value in 
the ONCOUNT field is zero. 


IHEM91 then returns control to IHEERR in 


order that each condition in the list can 
be raised. 
can be handled in one of two ways: 


1. By entering an ON-unit, with exit by 
either: 


ae A normal return 
b. A GO TO statement 


2. By system action 


These rules have to be considerably 
extended for handling a multiple-exception 
imprecise interrupt: 


1. ON unit for UNDERFLOW, FIXEDOVERFLOW, 


SIZE, OVERFLOW or ZERODIVIDE: 


a. Normal return: Next entry in the 
list is processed. If there are 
no more entries to be processed, 
then a return is made to the 
address in the PSW. 


b. GO TO statement: No more entries 
in the list are processed, and no 
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FIXEDOVERFLOW may be 


As described above, a condition 


information indicating the nature 
of these unprocessed entries is 
given. However, the ONCOUNT 
built-in function, when used in an 
ON unit, will return the number of 
entries remaining unprocessed. 


2. System action: 


ae For UNDERFLOW: When the error 
message has been printed, the next 
entry in the list is processed. 


b. For FIXEDOVERFLOW, SIZE, OVERFLOW, 
Or ZERODIVIDE: No further entries 
in the list are processed. If the 
program terminates as an immediate 
result of system action, messages 
are printed to indicate the nature 
of the unprocessed entries. 


3. ERROR raised for a data, 
specification, addressing or 
protection exception: No further 
entries in the list are processed. If 
the program terminates as an immediate 
result of the system action, messages 
are printed to indicate the nature of 
the unprocessed entries. 


In order to implement these rules, 
IHEERR tests for a multiple-exception 
imprecise interrupt after: 


1. Return from an ON unit: If a 
multi ple-exception imprecise interrupt 
exists, IHEM91 is entered at a second 
entry point in order to: 


a. Process the next entry 
b. Reduce the ONCOUNT value by one 


ce. Return to IHEERR 


2. Program termination caused by ERROR 
condition: If a multiple-exception 
imprecise interrupt exits, IHEM91 is 
entered at a third entry point. The 
condition list is processed in order 
to print out a message for each entry 
not handled at the time the program 
terminated. Program termination is 
completed when the list is exhausted. 


ONCOUNT Built-in Function 


The ONCOUNT built-in function returns a 
non-zero value only when this function is 
used in an ON unit entered as a result of a 
multiple-exception imprecise interrupt in a 
Model 91 or 195. In such a situation, the 
binary integer returned is the number of 
entries that remain unprocessed (including 
the current one) at the time the ONCQUNT 
function is used. 


Flush Instructions 


A program may not operate correctly on 
Model 91 or 195 if it requires 
identification of the instruction causing 
an imprecise interrupt. Similarly, it may 
not operate correctly if it requires that 
an imprecise interrupt is honored before 
some instruction later in the program is 
executed. However, the unwanted effects of 
imprecise interrupts can usually be 
eliminated by placing ‘flush‘ instructions 
at certain points in the program. A 
*flush* instruction is an Assembler 
Language instruction of the form: 


BCR x,90 


where x is not equal to zero. An 
instruction of this type is a no-operation 
instruction for all of System/360, but it 
is implemented in the Models 91 and 195 in 
such a way that its execution is delayed 
until all previously decoded instructions 
have been executed. 


If the OBJIN compiler option is 
specified, flush instructions are generated 
by the compiler at the following points in 
the program: 


1. Before every ON statement 

2. Before every REVERT statement 

3. Before code to set the SIZE condition 

4. For every null statement 

9. Before code to change prefix options. 
If both the OBJIN and the STMT options are 
specified, the compiler generates a flush 


instruction to precede every statement in 
the program. 


Model 91 and Model 195 Object-Time 
Diagnostic Messages 


If object-time diagnostic messages are 
issued as a result of an imprecise 


interrupt, the words "AT OFFSET..." are 


replaced by “NEAR OFFSET...*, since in 
these circumstances the instruction causing 
the interrupt cannot be precisely 
identified. 


After a multiple-exception imprecise 
interrupt on a Model 91 or 195, certain 
exceptions will remain unprocessed if the 
ERROR condition is raised before all the 
exceptions have been handled. If the 
program subsequently terminates as a direct 
result of the ERROR condition being raised 
in these circumstances, One or more of the 
following messages will be printed out. 


IHE8101 PROTECTION EXCEPTION 
UNPROCESSED AFTER 
MULTIPLE-EXCEPTION 


IMPRECISE INTERRUPT 


IHE81i1I1 ADDRESSING EXCEPTION 
UNPROCESSED AFTER 
MULTIPLE-~EXCEPTION 


IMPRECISE INTERRUPT 


IHE8121 SPECIFICATION EXCEPTION 
UNPROCESSED AFTER 
MULTIPLE-EXCEPTION 


IMPRECISE INTERRUPT 


IHE813I DATA EXCEPTION UNPROCESSED 
AFTER MULTIPLE-EXCEPTION 


IMPRECISE INTERRUPT 


IHE8141 ZERODIVIDE UNPROCESSED 
AFTER MULTIPLE-EXCEPTION 


IMPRECISE INTERRUPT 


OVERFLOW UNPROCESSED AFTER 
MULTIPLE- EXCEPTION 
IMPRECISE INTERRUPT 


IHE815I 
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CHAPTER 7: MISCELLANEOUS CONTROL PROGRAM INTERFACES . 


One function of the PL/I Library is to 
provide a standard interface with the 
control program which can be utilized by 
compiled code. Detailed implementation is 
described in Chapters 3, 4, and 5. The 
implementation described here concerns 
support for PL/I language statements and 
functions with a control program interface 
that does not fall into one of the 
categories discussed in those chapters. 
These are the PL/I statements DISPLAY, 
DELAY, STOP and EXIT, and the built-in 
functions TIME and DATE. 


Full and Minimum Control Systems 


The full control system of IBM System/360 
Operating System will enable the PL/I 
Library to issue macro instructions which 
support the above-mentioned statements and 


functions. The relationship is as follows: 
PL/I Macro instruction 
DELAY STIMER (WAIT) 
TIME TIME 
DATE TIME 
DISPLAY WTO, WTOR (WAIT) 


Thus, the library support for language 
features is as follows: 


DELAY: The execution of the current task 
is suspended for the required time. 


EXIT and STOP: Both these statements raise 
the FINISH condition and then cause 


normal termination of the PL/I program. . 


TIME: The time of day is returned to 
the caller in the form HHMMSStht where: 


HH = hours (24-hour clock) 
MM = minutes 

SS = seconds 
tht = tenths, hundredths and 


thousandths of a second 


74 


DATE: The date is returned to pe 
the caller in the form YYMMDD where: 


YY 
MM 
DD 


year 
month 
day 


DISPLAY: A message may be written on the 
console with no interruption in 
execution or, if a reply is expected, 
execution is suspended until the 
operator's reply is received. If the 
EVENT option is used when a reply is 
expected, execution is continued 
without interruption until a 
corresponding WAIT statement is 
encountered; execution is then 
suspended until a reply is received. 


The multiple console support (MCS) 
feature is supported for PL/I usage by 
means of the ROUTCDE and DESC (route code 
and message descriptor) parameters of the 
WTO macro instruction. This feature allows 
the use of one Master Console and up to 31 
secondary consoles. The values provided 
for ROUTCDE and DESC, in PL/I are: 


DISPLAY ROUTCDE = 2 
DESC = 7 
DISPLAY WITH REPLY ROUTCDE = 1 
DESC = 7 


ERROR MESSAGES (if SYSPRINT not available) 
ROUTCDE = 11 
DESC = 7 


The minimum control system does not 
support the TIME and STIMER macro 
instructions. Use of the DELAY statement, 
and TIME and DATE built-in functions will 
result in the ERROR conditions being 
raised. 


I/O EDITING AND DATA CONVERSION 


PL/I allows the user a wide choice in 
selecting the representation for his data, 
both on the external medium and internally 
in storage; considerable flexibility is 
permitted in specifying changes of data 
type and form. The library conversion 
package is designed to implement the full 
set of editing and conversion functions. 

To avoid unnecessary duplication of code, 
standard intermediate forms are used. This 
has the effect of reducing the number of 
library modules in the package to about 
fifty, to cover about two hundred logical 
conversions. To speed up processing, 
direct routines are provided for some of 
the most frequently used conversions, while 
the compiler generates in-line code for 
some of the simpler ones. 


To restrict further the storage 
requirements for the library conversion 
package, the F level compiler analyses the 
actual changes of data required for a 
particular execution. Sometimes these are 
not fully known at compile time, and then a 
worst case has to be taken. From this 
information, by use of the linkage editor 
LIBRARY statement and external references 
within the compiled modules, the loading of 
conversion modules is limited to those 
known to be required. This technique can 
be of considerable value, especially when 
only a small number of data types is used 
by the source programmer. Further details 


are provided in JBM System/360 Operating 


System: PL/I (F) Compiler, Program Logic 
Manual. 


With one exception, all the modules 
contained within the library conversion 
package are called by means of the PL/I 
standard calling sequence (described in 
"Linkage Conventions’, Chapter 2). The 
exception is IHEVCS (complex-to-string 
director) which is called by the operating 
system external standard calling sequence. 


The letters in the module name indicate 
the module usage; see Figure 34. 


STRUCTURE OF LIBRARY CONVERSION PACKAGE 


To perform a change from a source data item 
to a target data item may involve a 
succession of steps and the use of several 
individual library modules within the 
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package. The structure of the library 
conversion package is shown in Figure 36. 


In association with each individual 
step, the attributes of the source or the 
target fields, or of both, must be known. 
The required information is provided in the 
calling sequences. Each data item has a 
corresponding format element descriptor 
(FED) or data element descriptor (DED). 
With one exception, the formats of these 
control blocks are described in Appendix H. 
The exception is that of a DED generated at 
object time for communication between 
library modules. (See Figure 35.) 


Conversion involving 
external character 
data being converted 


CS a Qe Se en ee 7 
| Letters | | 
}---------~-------- { | 
11 2 3 4 5 6] Meaning | 
}------------------ }---------------------- { 
| I H E D | Director | 
}------------------ }--~------------------- { 
| I H E K | Picture check | 
}------------------ $---------------------- { 
| I H E V P | Conversion involving | 
| | packed-decimal | 
| | intermediate, except | 
| | IHEVPG and IHEVPH | 
p-------~-----~---- }---------------------- { 
| I H E V F | Conversion involving | 
{ | floating-point | 
| | intermediate { 
}------------------ }---------------------- { 
| I fH E V XK |} Conversion involving | 
| {| numeric fields | 
}------------------ }---------------------- { 
I H E V §S | Conversion involving | 

| strings | 

-~----------------- $----------------------4 
| | 

| 

| | 

| | 


| 

| 

L 

| 

| 

| 

| to type string 
}------------------}----------------------} 
i I H E V Q | Direct conversion to | 
| | improve performance | 
ft 
L 


ee weer no  - - -- - - --——- - {| 


I H E U P | Mode conversions | 
Figure 34. Module Usage indicated by 
Letters of Module Name 


This DED is created when it is necessary 
to convert a character representation of an 
arithmetic value to an intermediate coded 
arithmetic data type, prior to conversion 
to a string target. The form of this DED 
is the same as that for a coded arithmetic 
data item (CAD), and consists of a flag 
byte and precision bytes representing the 
quantities p and q. As for coded data, the 
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| | Bit l 
| }---------7------------------ q--------- y--------- q~-------- --------- q7-------- { 
| Code | 0 | 1 { 2 | 3 | 4 | 5 | 6 7 | 
}------ }--------- }--------- }~-------- +-~------- $--------- $--------- $--------- $--------- i 
| | | Non- | | l | | 
j=o | 1 | 1 {| sterling] Short | 1 | Decimal | Fixed | Real | 
}------}---------}---------}---------}---------}--------- 4--------- 4 ---------}---------4 
j=1 | 1 | 1 | Sterling| Long | 1 | Binary | Float {| Complex | 
eos Seen ae ae Eee een 5 eae pee eee yan Be ee ea a ee ee hea ee oe ee 
Note: Bits 0, 1 and 4 are always 1. The hexadecimal '10' superimposed on the DED flag 
byte indicates the presence of a halfword fixed point binary variable. Bit 3 is 
set to 1 and bit 6 is set to 0. 
Figure 35. DED Flag Byte for Character Representation of an Arithmetic Data Item 


flag byte defines the attributes of the 
corresponding data item; bit 1 is set tol 
to indicate that a character representation 
of an arithmetic value is referred to. 


Directors 


The structure chart makes frequent 
reference to ‘directors’. These modules 
are used to fulfil two main purposes: 


1. The matching of source element with 
target element, which may not be known 
at compile time. 


2. The controlling of the flow at object 
time by means of interpretative 
information passed to them. 


The latter function is best illustrated by 
the arithmetic conversion director 
(IHEDMA), where a single call determines 
the flow through a sub-package of over 
twenty arithmetic conversion routines. 
(See below in ‘Arithmetic Conversions‘. ) 


There are director routines at four 
levels. (See Figure 36.) They are: 


1. Complex format directors. 


2. Input/output format directors and the 
complex-to-string director. 


3. String-to-arithmetic and 
arithmetic-to-string directors. 


4. Arithmetic conversion director. 


All directors except the complex-to-string 
director can be called directly from 
compiled code; the complex-to-string 
director is invoked from the complex format 
directors or from list/data-directed input 
only. 


Any director can call any below it in 
the structure. 
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Edit-directed I/0 


Edit-directed transmission allows the user 
to specify the storage area to which data 
is to be assigned or from which data is to 
be transmitted and the actual form of the 
data on the external medium. The 
information concerning storage areas is 
specified in the source program by means of 
a data list, and the information about the 
form of the data on the external medium by 
means of a format list. 


The library conversion package is 
designed to implement the executable format 
scheme discussed in Chapter 3. This is 
done by the object time matching of list 
item and format item through the use of the 
director routines mentioned above. The set 
of I/O directors provided and their 
association with the PL/I data format items 
is shown in Figure 37. 


I/O EDITING 


Complex Directors: Complex format items on 
the external medium may have real and 
imaginary parts of differing attributes. 
When the list item and the taraet field are 
of type arithmetic, this situation is 
handled in the complex director by making 
consecutive calls for real and imaginary 
format items, and passing control to the 
particular format director associated with 
the format item. 





When the target field is a string, 
however, there are two problems with C 
format items. First, the data on the 
external medium must be scanned dynamically 
in order to deduce the attributes of the 
format item. The information derived from 
this is stored in a special DED. (See 
‘Structure of Library Conversion Package’ .) 
This DED is necessary for the conversion of 
all format items and constants. 


| Compiled | LWS 
(monn nnn rn T---------- 4 code ----------- Troon 5 Level 
| | | | | No. 
| v t------7--~---4 | | 
| p-—----~=--- == | | | 
{ Complex | | | | 
| r--—4 format }---------- | --~------------- > | | 4 
I { | director | | | | 
| t------y------4 | | 
| | | | | | 
| | | | | | 
| | Vv | V | 
| | p------------- | ------------- | 
| ; | Complex- | | |Input/Output | | 
| i; | to-string | | <----~---- 4 format }--------- >| 3 
| i | director | | | directors }-4 | 
| | t------ t------ ! t------y------! | | 
| | | | | | 
| <----~- | ----—--- | ------~---------- | ----------------- { | | 
| | | | | | 
| | | V | | | 
| | | fae SSeS asS= 7 | | | 
| | | | String<-> | | | | 
; | }-~------->| arithmetic  }---------- | -------- |------- >| 2 
| | | | directors -}-----—----- | ------- >| | 
| | t----~- 1------ ; | | | 
| | | | | | 
| <------ | ---------| -----------------4 | | | 
| | | | | | 
| | | V | V | 
| ; | Giese lem pets cra 1 | peseeese sees e= 1 | 
| | | | Mode | 1 | Decimal | | 
| | }-----—---- >| conversion = § |<--------- } | constant<-> | | 1 
| | | } routines | | | arithmetic | | 
| | | L------ 1------ , | t------7------ | 
| | | | | <------- 4 
| t—--——-—-—-— | ---~------------- | ---------------- >| | | 
Vv | | V | 
(oo SS==-- 7 | | gees ==4-= = 1 | 
} Arithmetic | | { | | Direct i { 
| conversion |<--------- 4——-—---~----~--~-- 4 [| | arithmetic | | 0 
| director | | | conversion | | 
 Sieoen ene eee ~---—--- J { t----------.-~- J | 
| a aac 1 | 
| | | | 
V V V V 
SS BO OES rs { (eS 2 Sees 1 Saas naa ac irerirae 
| Arithmetic | | Data | | Picture | | String | 
| conversion | | analysis | | checking | | routines | 0 
{ routines | | routines | } routines | ( | 
be Soe eae eee J Gore J a el ee PSO J Cee J 
Note: <-> indicates a conversion in either direction 
Figure 36. Structure of the Conversion Package 
Second, the base, scale and precision of imaginary parts of the C format item. Each 


the real and imaginary parts have to be 
compared, to determine the highest set of 
attributes, so that the form of the 
converted data in the string target may be 
known. This is done by invoking a special 
director, called the complex-to-string 
director, which performs the necessary 
analysis on the DEDs of the real and 


item is then converted by the rules of type 
conversion to coded complex and then to 
string. 


Input/Output Directors: The input/output 
directors named above (other than C format) 
perform three major functions. Because 
there are slight differences between input 
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‘Sea ln atau aati aaa Ge ee 1 

| PL/I | | Module name | 

| | =+---=> -------- { 

| format item | Director | Input | Output | 

}------------------ +---------------- +-------- +-------- { 

| Complex {| c | IHEDIM | IHEDOM | 

| | | | 

| Fixed and | F/E | IHEDIA | IHEDOA | 

| floating point \ | i | 

| | | | | 

| Bit string {| B { IHEDID | IHEDOD | 

| | | | 

| Character string | A | IHEDIB | IHEDOB | 

| | | | | 

| Picture | P(DEC,STL) | IHEDIE | IHEDOE | 

| | P(CHAR) | IHEDIB | IHEDOB | 

Gee ee a a a ee eee ed 

Figure 37. Input/Output Directors for PL/I Format Items 

re a ae a mr a ag cee eg eT ay et eee Sega pee Ee eS ey ne Oe et ee 1 
| INPUT | 
aati agate eka ecmenmree aca mS aaa aa a ce { 
| String value | List item | Conversion | 
}----------------- ~-~--}-------------------------- }-------~------------------------- { 
| | Arithmetic | Character to arithmetic | 
| Character string | Character string | Character string assignment | 
| | Bit string | Character to bit string | 
}~--------------------- }-------------------------- }--------------------------------- { 
| | Arithmetic | Bit string to arithmetic | 
| Bit string | Character string | Bit string to character string | 
| | Bit string | Bit string assignment | 
}--~------------------- }-------------------------- }--------------------------------- { 
| Arithmetic | Arithmetic | Arithmetic type conversion | 
; (including | Character string | Arithmetic to character string | 
| expression) | Bit string } Arithmetic to bit string | 
}------------ Si eset nema Lenn eo eee eee ae cas i an ob Ss cit ee a Sn ee oe ie aan om a a an a a oe eo eae 4 
OUTPUT 
(Sg eee ear ee a a aaa aaa mT re oa MST pe soy ee ae eg eee { 
| List item | String value | Conversion | 
}---------------------- }-------------------------- }--------------------------------- { 
| Arithmetic | Character representation | Arithmetic to character string | 
| | of data value | | | 
aa ar aac ; A a SR a a a 1 
| Bit string | Bit string in character | Bit to character | 
| | form | | 
a he eae rE cia » gies sec eal RAS RAR GE ICSE aE aE eer ao nee { 
| Character string {| Character string | Character string assignment | 
Ue oe ee er ee a ee ee es hea Se a a eae eae J 
Figure 38. Conversion for List/Data Directed I/0 


and output, the functions are described 
under these headings. 


Input: A call is made to IHEIOD to request 
w bytes and a data field pointer. If the w 
bytes can be obtained from the current 
buffer, the address returned to the input 
director is that of the data field in the 
buffer itself. If not, a VDA is obtained 
and the requisite field of w bytes is built 
up in the dynamic area. The VDA address is 
stored in WSDV in the LCA. 


These two conditions are normal. If, on 
the other hand, an abnormal return occurs 
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at this point, this siaqnifies that an. 
ENDFILE condition exists and that a return 
has been made from an ENDFILE on-unit. In 
this case, the I/O director must return 
control to the code associated with the 
next PL/I source statement, which is 
pointed at by the second word of 
pseudo-register IHEQCFL. 


If there is no abnormal return, the 
target DED is inspected by the director 
routine and the first stage of the 
necessary conversion process is initiated 
by means of a suitable call to a routine 


below the input director level. (See 


structure chart, Figure 36.) 


When the conversion has been completed 
and the data item assigned to the list 
item, the input director calls the I/0 
package again. At this stage, the I/0 
routine tests for the TRANSMIT condition, 
and, if necessary, calls IHEERR, to specify 
that the TRANSMIT condition is active, and 
that the format item transmitted is 
therefore suspect. In addition, any VDA 
that has been allocated is freed. 


Output: A call is made to the library I/0 
package to obtain an address for the 
external data item. If the w bytes 
specified can be satisfied within the 
current buffer, the address of the current 
buffer pointer is returned; if not, a VDA 
is obtained and the address of this dynamic 
storage is passed back. The source DED is 
then inspected and a call is made to the 
first subroutine in the conversion package 
to perform conversion. 


After assignment of the data item to a 
buffer area or VDA, a call to the 
appropriate I/O routine is made from the 
output director. If a VDA was used, the 
output field is split off into the 
appropriate buffers and the dynamic storage 
released. 


For both input and output, control is 
finally returned to compiled code. 


List- and Data-directed Input/Output 


The total set of conversions required by 
list/data-directed I/O is shown in Figure 
38. 


Since all the conversions represented 
deal with change of data from one internal 
representation to another, the conversion 
package is fully capable of performing the 
conversion for list/data-directed I/O. The 
type conversions are fully defined in the 
PL/I language and the modules that 
implement them are given below. Some 
examples of list/data-directed I/O are 


included in IBM System/360 Operating 
System: PL/I (F) Programmer's Guide. 


MODE CONVERSIONS 


Since data may be declared COMPLEX, and 
complex values may be written or read by 
list-directed and data-directed input and 
output, or by the C format item, two 
routines are provided to facilitate 


conversions of mode during I/O editing and 
during conversions between internal 
arithmetic and string data. 


TYPE CONVERSIONS 


Four director routines are provided to 
control the flow which enables changes 
between data of type string and data of 
type arithmetic, as required by the PL/I 
language. These routines are used by 
list-, edit- and data-directed I/O and in 
some internal conversions. 


a ea ics Nos ee ee ee ee 1 
TO: | 
| SR fale a 
| jArithmetic] String | 
}--------7--------- { 
i { | Bit |Character| 
}----------- +---------- }--------}--------- { 
| FROM: | | | | 
— | | 
| Arithmetic| - | IHEDNB | IHEDNC | 
l | | | | 
| Bit string| IHEDBN | - | - | 
| | | | | 
| Character | IHEDCN | ~ | - | 
| string | | | | 
beceeek ceoee te ee ; ee a J 
Figure 39. Modules for Type Conversions 


STRING CONVERSIONS 


A set of generalized interpretive routines 
is provided to support the possible string 
conversions and assignments that may exist. 
Each module interrogates source and target 
information contained in the string dope 
vectors and DEDs in order to handle 
truncation, padding, and alignment for 
fixed and varying strings. Figure 40 shows 
the modules provided; it should be noted 
that there is no difference between a 
source character string with a picture and 
one without, as once the data has been 
checked into the source field, no further 
use is made of the picture. 


| | TO: | 
aaah. mead ane) GOT ae aa eRe 
| {| Bit |Character|Character with| 
| | | | picture 
--~------- }------}---------}--------------4 
| FROM: | | 
[Bit | IHEVSA| IHEVSB | IHEVSF | 
| | | | | 
|Character|IHEVSD| IHEVSC | IHEVSE | 
j 


= 2 sic Sc tac lsc nes ee I ti ea es is sk i lit ei eh dso cl = oe eae =a 


Figure 40. Modules for String Conversions 
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ARITHMETIC CONVERSIONS 


A direct routine IHEVQA converts 
floating-point data to fixed-point binary, 
in order to provide fast processing of this 
frequently used routine. Normally, 
however, all conversions (including this 
one) are dealt with by the library 
conversion package. 


This package carries out editing and 
conversions for all type arithmetic source 
fields which have type arithmetic target 
fields. It also handles conversions of 
format items and constants, which are 
character representations of arithmetic 
type data. The flow control through this 
subpackage is.achieved by the arithmetic 
conversion director described below. 


The method employed is to use an 
intermediate form of representation 
according to the form of the source data 
and to relate this intermediate form to the 
target data, either by direct conversion or 
by use of a second intermediate form (which 


implies radix change). The two 
intermediate forms in use are: 


1. Packed decimal intermediate (PDI) 


This consists of 17 digits and a sign, 
together with a one-word scale factor 
(WSCF) in binary representing powers of 
ten. 


2. Long floating-point intermediate (FPI) 


This is the standard internal form, and 
consists of 14 hexadecimal digits. 


The logical flow through the package is 
shown in Figure 41. 


The arithmetic conversion director 
(IHEDMA) links together the modules 
required for a particular arithmetic 
conversion. It is called either directly 
by compiled code or by other director 
routines. The flag bytes in the source and 
target DEDs are interrogated to determine 
which modules are required for the current 
conversion and their order of execution. 


i 1 
| Arithmetic | 
poo oon + - -- ---- |] conversion }----—-----—---—--- - - - --- - - --- +--+ +--+ -- =; 
| | director | { 
| p-------------1 t—--—------J p------------- 1 | 
| | Sterling | VKC | | | 
b—>jnumeric field|<--------——-----7 p----- 4 Binary |<--4 
i | | VKG | | VPG | constant | | 
ee | bee J 
| | | 
(. .-..====->=- === 1 | | -———-=----—-= 1 | 
| | Decimal | VKB | | VPB | Binary | | 
-->|numeric field|<-------—- ---- -------~------>| fixed | <--4 
; | data j VKF | | VFD | data | | 
fb ee J | | Pi 2s52 4 cee J 
{ V V | 
| ay ee ee (Sea gt os 1 a eam an | 
} | Decimal | VPF | Library | VPA | Library | | 
b—> | fixed | <----->| packed decimal |<----- >| floating-point | | 
i | data | VPD | intermediate | VFA | intermediate | | 
J bee J OO eae rete ann ee ene ee ey re J | 
| A A | 
| ---------=---4 p-------------1 | 
| | ¥F format | VPE | | VFC | Floating- | | 
b->| character | <-----~-~--~--~---4 -}----- ---—----- >| point |<--4 
| | string | VPB | VFE {| data l | 
{| t----—_-----~J | | a ee ne ee J 
| | | | 
[0 po-----——=----4 poma-- === ---- | 
| | E format ; VPE | | | Bit string | | 
L->| character | <------—--—------4 t_---—~-—---—-—- >| constant | <+—-J 
| string { VPC VPH | 
biceaseeea teed (2632 eee J 


Note: The three-letter names, e.g., VKC, are the last three letters of the module name. A 
name above the flow lines indicates a conversion from left to right; a name below 
the line indicates a conversion from right to left. 


Figure 41. 
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Structure of the Arithmeric Conversion Package 


The library communication area is used to 
record information required by successive 
modules as follows: 


WBR1 Address of entry point of second 
module 

WBR2 Address of entry point of third 
module (if required) 

WRCD Target information 


The conversion director then passes 
control to the first module in the chain; 
the first transfers control to the second, 
and so on until the conversion is complete. 
The last module returns to the program 
which called the conversion director. All 
the modules which can be first in the chain 
set up by the conversion director use the 
source parameters passed to this director. 
The first conversion is always to the 
intermediate form of the same radix as the 
source. The results are stored in the 
following LCA fields: 

WINT Binary results 
WINT 
WSCF 


Decimal results 


Three modules in the arithmetic package 
deal with data on the external medium. Two 
modules handle the output of F and E format 
items from packed decimal intermediate 
format, and the third provides conversion 
from F or E format items to packed decimal 
intermediate format. The LCA fields used 
for these modules are: 


WFED A(FED) at input 

WFDT A(FED) at output 

WSWA Switches 

WwSWC 

WOCH A(Error character): for ONCHAR 
built-in function 

WOFD Dope vector for ONSOURCE built-in 


function 


DATA CHECKING AND ERROR HANDLING 


Checking is carried out on data on the 
external medium for edit-, data- and list- 
directed input and on internal data items 
taking part in conversions. 


Edit Directed 


All data described by a picture is matched 
against the picture description. When a P 
format item is read in, this checking is 
performed by one of three picture check 
routines (decimal, sterling, and character) 
which is called by the appropriate input 
director. 


F/E format items are checked against the 
format element descriptor (FED). The 
validity of the characters in the data item 
is investigated prior to conversion to 
packed decimal intermediate format. 


If B format items are assigned in the 
target DED to a bit string, the items are 
checked in the character-to-bit module. 
Otherwise, a pre-scan within the B format 
input director checks that all characters 
in the string are either zero or one. 


If A format or B format is specified on 
input without a w specification, the 
compiled code calls IHEDIL (illegal-input 
format director). This routine calls the 
execution error package, pasSing an error 
code. This causes a message to be printed 
and the ERROR condition to be raised. 


List/Data-Directed 


Within the conversion package, the 
constants which are converted to arithmetic 
are checked in the appropriate internal 
conversion modules... 


Decimal constants are converted by the 
F/E-to-PDI routine and are therefore 
checked by that routine as above. 


Binary constants are checked prior to 
conversion to floating-point intermediate. 


Bit string constants are checked prior 


to conversion to floating-point 
intermediate. 


Internal Conversions 


Checking of data is provided for the 
following: 


1. Character string to arithmetic. 
2. Character string to bit string. 
3. Character string to pictured character 


string. 
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4. Bit string to pictured character 
string. 


In cases i to 3 above, if an invalid 
character is found the CONVERSION condition 
is raised; in case 4, the ERROR condition 
is raised. 


When CONVERSION is raised, an error code 
is passed to IHEERR. The error code passed 
depends: 


1. On the type of operation (internal, 
I/O, or I/O with TRANSMIT condition 
raised). 


2. On the various formats and conversions 
involved. These consist o€: 


F format 

E format 

B format 

Character string to arithmetic 

Character string to bit string 

Character string to pictured 
character string 

P format (decimal, character and 
sterling) 


Different ONCODE values are set for each, 
and may be interrogated in an on-unit 
provided for the CONVERSION condition. If 
the condition is associated with I/O, it is 
also possible that a TRANSMIT condition may 
be active. This can be tested in the 
on-unit for CONVERSION. A list of ONCODE 


System: PL/I (F) Programmer's Guide. 


The conversion package routines set the 
following information before invoking the 
execution error package: 


WOFD Dope vector for field scanned 
WOCH Address of character in error 
IHEQERR Value of the error code. For 


I/O editing, a1 bit is set in 
bit zero. 


Bits 12 to 15 are set according 
to the conversion being 
performed. (See Figure 42.) 


In addition to the occurrence 
of the CONVERSION error, the 
SIZE condition can also occur in 
the conversion package. Once 
again, a distinction is made 
between internal conversions and 
conversions involving the 
external medium. In the latter 
case, bit zero in IHEQERR is 
again set to one. 
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| Conversion Code 

| F format 

| E format 

| B format 

| Character string to 
| arithmetic 

| Character string to 
| bit string 
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| 

| 

| 

| 
L 


n 


Character string to 
pictured character string 

P format (decimal) 

P format (character) 

P format (sterling) 
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Figure 42. Conversion Code Set in IHEQERR 


In certain cases an illegal conversion 
may be requested or an invalid parameter 
may be passed to a conversion routine. In 
these cases the conversion package calls 
the error-handling subroutine, having set 
register RA to point to an error code. 
This causes a message to be printed which 
describes the error found; the 
error-handling subroutine then raises the 
ERROR condition. 


If a CONVERSION error occurs, the 
program can proceed in three ways: 


1. If system action is specified, a 
message will be printed and the ERROR 
condition raised. 


2. If CONVERSION is disabled, the 
conversion will continue, ignoring the 
character in error. 


3. If an on-unit exists, it will be 
entered. If the on-unit returns 
control to the conversion routines, 
they will assume that either the 
ONCHAR or ONSOURCE pseudo-variable has 
been used to correct or replace the 
character or field in error, and will 
automatically retry the conversion. 


Note: If the pseudo-variables have not 
been used to correct the error, and if the 
On-unit attempts to return control to the 
conversion, a message will be printed and 
the ERROR condition raised. 


COMPUTATIONAL SUBROUTINES 


Computational subroutines within the PL/I 
Library supplement compiled code in the 
implementation of operators and functions 
within three main groups. These groups 
are: 


1. Arithmetic evaluation 


2. Mathematical functions 


3. Array functions 

In addition to the description provided 
in this document, detailed information on 

algorithms and performance is published in 


IBM System/360 Operating System: PL/I 
Subroutine Library: Computational 
Subroutines. 


A number of error and exceptional 
conditions not directly covered by 
PL/I-defined ON conditions may occur in 
these subroutines. In these cases, a 
diagnostic message is printed and the ERROR 
condition raised. By use of the ONCODE 
built-in function, the cause of interrupt 
may be ascertained in an ERROR unit and 
appropriate action may be taken. A list of 
the error messages and ONCODEs is given in 


IBM System/360 Operating System: PI/I (F) 
Programmer‘s Guide. 


When an aggregate of data items is being 
processed, the indexing through the 
aggregate is achieved by in-line code, as 
the library routines generally handle 
individual elements only. The array 
functions, however, perform their own 
indexing, so that only a single call from 
compiled code is made. 


For modules handling data in coded form, 
character six of the module name indicates 
the type of data concerned; the meanings of 
this character are given in Figure 43. 





Pre ese te oe Oe ee ee a 
| Data | Character ; 
pm nanan nnn nnn nnn nnn 

| Real or j; 
i Internal form | Real Complex Complex | 
}--—-------—------- }---—-—-- --------——-| 
| Binary ij B U | 
| Packed decimal | oD V | 
{| Binary or | | 
j packed decimal | F xX | 
| Short float | s W G | 
| Long float i 2 Z H | 


Relationship of Data Form and 
Sixth Character of Module Name 


Figure 43. 


MATHEMATICAL FUNCTIONS 


THe library provides subroutines to deal 
with all float arithmetic generic functions 
and has separate modules for short and long 
precision real arguments, and also for 
short and long precision complex arguments 
where these are admissible. 


Linkage to all mathematical subroutines 
is by means of the operating system 
standard. 


Where evaluation or conversion of an 
argument is necessary, this is done prior 
to the invocation of the library module. 
Hence, all arguments passed to the 
mathematical subroutines must be of scale 
FLOAT. As such, it is assumed that the 
arguments are normalized in aligned 
fullword or doubleword fields for short or 
long precision respectively. The results 
returned are normalized similarly. 


Ce ee a ap ee ae GP OE GS SE SF SSD BD SS 6 a Ee OP 62S 6 aaa a 


| Real Arguments | 


}—---—-------------—---4--------------—--f 


j | | Short | Long | 
| Function | float | float | 
p——--—------—-- -- —-—--- f= === f= = -| 
| SQRT | IHESQS | IHESQL | 
| EXP | IHEEXS | IHEEXL | 
| LOG, LOG2, LOG10 | IHELNS | IHELNL | 
| SIN, COS,SIND,COSD | IHESNS | IHESNL | 
| TAN, TAND | IHETNS | IHETNL | 
| ATAN, ATAND | IHEATS | IHEATL | 
| SINH, COSH | IHESHS | IHESHL | 
| TANH | IHETHS | IHETHL | 
| ATANH | IHEHTS | IHEHTL | 
| ERF, ERFC | IHEEFS | IHEEFL | 
cia weimai ie eaten Cele eh a 
a eg ee ae gS eee ee 
| Complex Arguments | 
p----—----------—----- ~y--------1--------4 
| ] Short | Long | 
! Function | float | float | 
—---------------—----- }-------- }-----—- { 
| SQRT | IHESQW | IHESQZ | 
| EXP | IHEEXW | IHEEXZ | 
| LOG | IHELNW | IHELNZ | 
| SIN,COS, SINH, COSH | IHESNW | IHESNZ | 
| TAN, TANH | IHETNW | IHETNZ | 
] ATAN, ATANH | IHEATW | IHEATZ | 
bee a eee eae ee { eres 
Figure 44. Mathematical Functions 


ARITHMETIC OPERATIONS AND FUNCTIONS 


‘Library arithmetic modules provide support 
for all those arithmetic generic functions 


and operations for which the F level 
compiler neither generates in-line code nor 
(as for the functions FIXED, FLOAT, BINARY, 
and DECIMAL) uses the library conversion 


package. 


Linkage between compiled code and the 


arithmetic modules is established by means 


of the operating system standard for the 
functions supported and by means of the 


PL/I standard for the operators supported. 


The module description summaries provide 
information about linkage to individual 


modules. 
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Fixed-point data often require data 
element descriptors (DEDs) to be passed in 
order to convey information about precision 
(p, q). Binary data is always assumed to 
be stored in a fullword correctly aligned, 
with 0 < p < 31. Decimal data is always 
assumed to be packed in FLOOR (p/2) + 1 
bytes, where 0 < p < 15. Where such fields 
introduce high-order digits beyond the 
specified precision, these digits must not 
be significant. 


In decimal routines, the target area is 
assumed to be of the correct size to 
accommodate the result precision as defined 
by the language. 


Where assignment to a smaller field is 
required, the compiled code should generate 
an intermediate field for the result and 
subsequently make the assignment. This 
does not apply to ADD, MULTIPLY and DIVIDE 
with fixed-point decimal arguments, which 
perform the assignment themselves. Such 
action by compiled code avoids much 


unnecessary object-time testing and enables 
a Clear distinction to be made between SIZE 
and FIXEDOVERFLOW conditions. 


Floating-point arguments are assumed to 
be normalized in aligned fullword or 
doubleword fields for short or long 
precision respectively; the results 
returned are similarly normalized. 


ARRAY FUNCTIONS 


The library provides support for compiled 
code in the implementation of the PL/I 
array built-in functions SUM, PROD, POLY, 
ALL, and ANY. Calls to array function 
modules are by means of the operating 
system standard; the indexing routines, 
which are used internally by the library, 
use the PL/I standard calling sequence. 


| ARITHMETIC OPERATIONS | 


Siu a Sc cea ema a : ari peu craiay Weare eg ee eee { 
i Operation | Binary | Decimal|{ Short | Long | 
| { fixed | fixed | float | float | 
t ee ee ae es wre em ee rm a ree ae a ee oe ee nee a ee a ee ee ee ee ee ee , rn ; eee i a ss a i st ch Saks ae | 
| Real Operations | 
Sa ee baa ea a asian ae aa a aaa aaa 1 Sonne aaa { 
| Integer exponentiation: x**n | IHEXIB | IHEXID | IHEXIS | IHEXIL | 
| General exponentiation: x**y | | = | IHEXXS | IHEXXL | 
| Shift-and-assign, Shift-and-load | | IHEAPD | = | = | 
{-—------------~ ~~ ---- -- -------- +--+ -- ee Geen nee [a eee a { 
| Complex Operations | 
|--------------------------------------- y-------- y-------- y-------- y-------- { 
| Multiplication/division: 24*Z2, Z1/Z2 | IHEMZU | IHEMZV | - | - | 
{| Multiplication: 24,¥*Z2 | - | - | IHEMZW | IHEM2ZZ | 
| Division: 2Z4/Za2 | = | = | IHEDZW | IHEDZZ | 
{| Integer exponentiation: z*#n | IHEXIU {| IHEXIV | IHEXIW | IHEXIZ | 
| General exponentiation: 2,**z, | - | = | IHEXXW | IHEXXZ | 
ea a we ap Pe ec a Pn nn ne no ep En PO ere y eee ee bee eee Peo Sosos | en ee J 
a a a a ca cg GSE CO Og ei ae 7 

| ARITHMETIC FUNCTIONS l 

paSseS See seEses a= oo ee 7 Sean re cae { 

| Function | Binary | Decimal| Short | Long | 

| | fixed | fixed | float | float | 

[~--.~----- dpa Se ena ers Pees ee ee are x eae espe ner 

| Real Arguments | 

}---------- y-------- -------y--------1-------- 

| MAX, MIN | IHEMXB | IHEMXD | IHEMXS | IHEMXL | 

| ADD | - | IHEADD | - | - | 

}--------~—- 1 eee ; ee po ae eee | ae ae ee 4 

| Complex Arguments | 

|----------7-------- ~------y--------7-------- 

| ADD | - | IHEADV | - | - | 

| MULTIPLY | IHEMPU | IHEMPV | - { - | 

| DIVIDE | IHEDVU | IHEDW | - | - 

{| ABS {| IHEABU | IHEABV | IHEABW | IHEABZ | 

betes Sieccceeca Densscies aia nina y ener | eee J 

Figure 45. Arithmetic Operations and Functions 
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Simple arrays, and | 
| interleaved arrays of 


: 
| | 
| 
| 


Interleaved string | 
{| arrays with fixed- | 
| variable-length strings| length elements | 


~-~~------}----~------- —---------- } ----------------------{ 
| Indexers | IHEJXS | IHEJXI | 
| ALL, ANY | IHENL1 | IHENL2 | 
Ree ee ee Sia ase BSS eae ea mn en eed enn ae elvan J 


Note: IHEJXI is also used for indexing 
through interleaved arithmetic arrays 


eae So ee Se ee ee 1 
| PL/I | Fixed - point | Floating-point arguments | 
| functions | arguments —--~-—- ~~ ey — ee 4 
| | } Short precision } Long precision | 
| | -—-- =< y= == SASS DAE SUEPRDEP SERENE fonnne nn aqonne nono = a 
| | Simple |Interleaved| Simple interleaved | Simple |Interleaved| 
}--~-----------}----—-- }----------- }-------- +----------- }--------+----------- { 
{| SUM real | IHESSF | IHESMF {| IHESSG | IHESMG | IHESSH | IHESMH | 
| Complex | IHESSX | IHESMX {| IHESSG | IHESMG | IHESSH | IHESMH 
| | | | | | | | 
} PROD real | IHEPSF | IHEPDF | IHEPSS | IHEPDS | IHEPSL | IHEPDL | 
| complex | IHEPSX | IHEPDX | IHEPSW | IHEPDW | IHEPSZ | IHEPDZ~ | 
| }--------1-~---------}--------4--~--~------}--------4-~---------4 
| POLY real | IHEYGF | IHEYGS | IHEYGL | 
| complex | THEYGX | ITHEYGW | IHEYGZ | 
Bs se Bene pin I a oe ree a Ree OE ee J 
Figure 46. Array Indexers and Functions 


In all cases, the source arguments are 
arrays and the function value returned is a 
scalar. The evaluation of this function 
value requires only one call from compiled 
code, indexing through the array being 
handled internally within the library. 


In the interests of efficiency, two sets 
of modules are provided: those which deal 
with arrays whose elements are stored 
contiguously (simple arrays), and those 
which also deal with arrays whose elements 
are not in contiguous storage (interleaved 
arrays). 


In order to deal with array element 
addressing, the library modules require an 
array dope vector (ADV or SADV) to be 
passed aS an argument. The format of these 
dope vectors is described in Appendix H. 
The number n, the number of dimensions of 
the array, is required in addition to the 
ADV or SADV, and is passed as a Separate 
argument. 


The PL/I language requires that the 
scalar values resulting from the use of the 
array functions, SUM, PROD, and POLY, 
should be floating-point. Since the 
library modules are addressing each array 
- element successively, the necessary calls 
to the conversion routines (to change scale 
from FIXED to FLOAT) are made from the SUM, 
PROD, and POLY modules which have 
fixed-point arguments. In the case of ALL 
and ANY functions, it is expected that any 


necessary conversion to bit string will be 
carried out before the library is invoked. 


STRING SUBROUTINES 


The library string package contains modules 
for handling both bit and character 
Strings. Generally, individual modules 
handle a particular function or operation 
for bit or for character string; in the 
interests of efficiency however, additional 
modules are provided to deal with 
byte-aligned data for some of the bit 
String operations. 


The functions LENGTH and UNSPEC are 
handled directly by compiled code; support 
for BIT and CHAR is provided in the library 
conversion package. 


Linkage to the string subroutines is by 
means of the operating system standard for 
the functions SUBSTR, INDEX and BOOL, and 
by the PL/I standard for all others. The 
functions REPEAT, HIGH, and LOW use the 
PL/I standard as they are implemented as 
entry points to the concatenation and 
assign/fill routines. 


The address and the maximum and current 
lengths of a string are passed to library 
modules by means of string dope vectors. 
All string lengths supplied in SDVs are 
assumed to be valid non-negative values; 
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unpredictable results will ensue if this 
condition is not satisfied. 


Conversions (e.g. of decimal integers 
into binary integers for functions such as 1. 
REPEAT) and evaluation of expressions are 
handled by the compiler, which is also 
responsible for recognising instances of 
byte-alignment which are suitable for the 
byte-aligned bit functions provided. 


The general design of the string package 
is influenced by the concept that complete 
evaluation of the right-hand side of an 2. 
assignment statement occurs before the 
assignment. In this evaluation, there is 
usually an intermediate stage in which a 
partial result is placed in a field acting 
as a temporary result field. This does not 
prevent the compiler from optimizing by 


providing the actual target field of the 
assignment as the temporary result field, 
subject to the following. conditions: 


If the target field is the same as a 
field involved in expression 
evaluation, an intermediate area is 
required to develop the result (unless 
otherwise stated in the module 
description summaries). For example, 
A= B {| A requires an intermediate 
field, but A = A & B does not. 


Padding of fixed-length strings does 
not occur automatically when a string 
operation is performed, except in the 
case of assignment of fixed-length 
character strings and fixed-length 
byte-aligned bit strings. Separate 
routines are available for padding. 


a2 see eS Par Sees yp ew ee es ai we eae 
| PL/I | PL/I | Bit String | Character | 
| Operation | Function }---------- .r------- -- { String | 
i. | | General |Byte-aligned| | 
}------------ }---------- }---~------ }------------ }--------- { 
| And | = | Use BOOL | IHEBSA | = | 
| Or | - | Use BOOL | IHEBSO | - | 
| Not | - | Use BOOL | IHEBSN | - | 
| Concatenate| REPEAT | IHEBSK | - | IHECSK | 
| Compare | = | IHEBSD | IHEBSC | IHECSC | 
| Assign | ~ |} IHEBSK | IHEBSM | IHECSM | 
{| Fill | = | IHEBSM | - {| IHECSM | 
i = | HIGH/LOW | - | oa | IHECSM | 
| - | SUBSTR | IHEBSS | - | IHECSS | 
| ~ | INDEX | IHEBSI | = | IHECSI | 
| - | BOOL | IHEBSF | - | ~ 
ee ee hy eee era ear aie Oe ea ee es ee a ena J 
Figure 47. String Operations and Functions 
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This section provides information about 
individual modules of the PL/I Library. It 
serves as an introduction to the more 
detailed accounts given in the prefaces to 
the program listings. A brief statement of 
function is given; also provided are full 
specifications of linkage and inter-modular 
dependency. Since many library modules 
invoke the execution error package 
(IHEERR), no reference is made to this 
module in the ‘Calls’ section. Appendix G 
gives the lengths of the modules and 
indicates their locations (SYS1.PL1LIB or 
SYS1.LINKLIB). 


CONTROL PROGRAM INTERFACES 


The ‘'Calls' and ‘Called by‘ sections 
include the use of the LINK and XCTL macros 
to pass control. 


DATA PROCESSING 


All integral values specified in the 
‘Linkage’ section of the module description 
will be represented internally as fullword 
binary integers. Target fields will also 
be fullwords unless otherwise specified or 
implied (for example, for long 
floating-point results). 


When FIXED data is passed to the 
library, a DED is associated with it in the 
linkage. In cases where the DED is not 
interrogated, the appropriate entry in the 
*Linkage‘ section is marked with an 
asterisk. 


Complex arguments are assumed to have 
real and imaginary parts stored next to 
each other in that order, so that the 
address of the real part suffices for both 
of them. Both parts are described by the 
same DED. 


I/Q Editing and Data Conversions 


Target fields may, if desired, be 
overlapped with source fields in all cases 
except IHEVSA, IHEVSB, IHEVSC, IHEVSD, 
IHEVSE, and IHEVSF. 
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Strings: A source string field may 
coincide with a target string field in the 
modules listed in Figure 48. It should be 
noted that use of the same address for the 
dope vectors of source string and target 
string is not generally permitted, even 
though the string fields themselves may be 
overlapped. The exceptions to this are the 
entry points IHEBSKK and IHECSKK, where a 
considerable saving of time can be obtained 
by using the same address for both the 
first source and target SDVs. 


| Source/target coincidence | 


c 
| 

}---------------y--------------] 
| Module | First source |Either source | 
| | field only | field | 
}----------4---------------}------—------} 
{| IHEBSA | Yes | - r 
| IHEBSO | = | Yes | 
| IHEBSK | Yes | - ; 
| IHEBSM | Yes - | 
| IHEBSF | ~ | Yes | 
| IHECSK | Yes - | 
{| <IHECSM | Yes | - | 
bs eee ae eee eee dee ee od 


Coincidence of Source and 
Target Fields in some String 
Modules 


Figure 48. 


The first byte of the result produced by 
the comparison modules IHEBSC, IHEBSD, and 
IHECSC contains: 


Bits Contents 





0 to 1 Instruction length code 01. 

2 to 3. Condition code as below 

4 to 7 Program mask (calling routine) 

The condition code is set as follows : 
00 Strings equal 


01 First string compares low at first 


inequality 
10 First string compares high at first 
inequality 
Arithmetic: Target fields may, if desired, 


be overlapped with source fields in all 


cases except IHEXIU, IHEXIV, IHEXIW, 
IHEXIZ, IHEXXL and IHEXXS. 


Mathematical: Target fields may, if 
desired, be overlapped with source fields 
in all cases except IHEEFL, IHEEFS, IHELNW, 
IHELNZ, IHESQW and IHESQZ. 
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MODULE SUMMARIES 


IHEABN 
Entry point: IHEABND 
Function: 


Default module for system ABEND feature. 
Sets function code in register 15. 


Linkages 

None 
Called by: IHEERR 
IHEABU 
Entry point: IHEABUO 
Function: 


ABS (z), where z is complex fixed-point 
binary. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(z) | 

*A(DED for 2) 

A (Target) 

*A(Target DED) 
Called by: Compiled code 
IHEABV 
Entry point: IHEABVO 
Function: 


ABS(z), where z is complex fixed-point 
decimal. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(z) 
A(DED for z) 
A(Target) 
A(Target DED) 
Called by: Compiled code 
IHEABW 
Calls: IHESQS 
Entry point: IHEABWO 
Function: 
ABS(z), where z is complex short 
floating-point. 
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Linkage: 


RA: A(Parameter list) 
Parameter list: 

A(z) 

A(Target) 


‘Called by: Compiled code, IHESQW 


LHEABZ 
Calls: IHESQL 


Entry point: IHEABZ0O 


Function: 
ABS(z), when z is complex long 
floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(z) 
A(Target) 
Called by: Compiled code, IHESQZ 
ITHEADD 
Calls: IHEAPD 
Entry point: IHEADDO 
Functions 
ADD(x,y,P,q), where x and y are real 
fixed-point decimal, and (p,q) is the 
target precision. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A(DED for x) 
A(y) 
A(DED for y) 
A(Target) 
A(Target DED) 
Called by: Compiled code, IHEADV 
IHEADV | 


Calls: IHEADD 


Entry point: IHEADVO 


Function: 


ADD(w,ZeP,qQ), where w and z are complex 
fixed-point decimal, and (p,q) is the 
target precision. 


Linkages 


RA: A(Parameter list) 
Parameter list: 

A (w) 

A(DED for w) 

A(z) 

A(DED for z) 

A(Target) 

A(Target DED) 


Called by: Compiled code 


ILHEAPD 
Calls: IHEERRB 
Entry point IHEAPDA 
Function: 
To assign x to a target with precision 
(pa, Ga), where x is real fixed-point 


decimal with precision (pi, qa), and py 
< 31. 


Linkage: 


RAs A(x) 

RB: A(DED for x) 

RC: A(Target) 

RD: A(DED for target) 


Called by: IHEADD, IHEDVV, IHEMPV 


Entry point IHEAPDB 
Function: 


To convert x to precision (31,qa), 
where x is real fixed-point decimal 
with precision (p,, qa), and py s 31. 
Linkage: As for IHEAPDA 
Called by: IHEADD, IHEDVV 
LHEATL 
Entry point IHEATL1 
Function: 


ATAN(x), where x is real long 
floating-point. 


Linkage: 
RA: A(Parameter list) 
Parameter lists: 
A(x) 
A(Target) 


Called by: Compiled code 


Entry point IHEATL2 


Function: 


ATAN(y,x), where x and y are real long 
floating-point. 


Linkage: 


RAs A(Parameter list) 
Parameter list: 

Ay) 

A(x) 

A(Target ) 


Called by: Compiled code, IHEATZ, IHELNZ 
Entry point IHEATL3 
Function: 


ATAND(x), where x is real long 
floating-point. 


Linkage: 
RA: A( Parameter List) 
Parameter list: 
A (x) 
A(Target) 


Called by: Compiled code 


Entry point IHEATL4 


Functions: 


ATAND(y,x), where x and y are real long 
floating-point. 


Linkages 


RA: A(Parameter list) 
Parameter list: 

Aly) 

A (x) 

A(Target) 


Called by: Compiled code 


IHEATS 
Entry point IHEATS1 
Function: 


ATAN(x), where x is real short 
floating-point. 


Linkages 
RA: A( Parameter list) 
Parameter list: 
A (x) 
A (Target ) 


Called by: Compiled code 
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Entry point IHEATS2 


Functions: 


ATAN(y,x), where x and y are real short 
floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 

A(y) 

A(x) 

A(Target) 


Called by: Compiled code, IHEATW, IHELNW 


Entry point IHEATS3 
Function: 
ATAND (x), where x is real short 
floating-point. | 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A(Target) 


Called by: Compiled code 


Entry point IHEATS4 


Function: 


ATAND(y,x), where x and y are real 
short floating-point. 


Linkages 


RA: A(Parameter list) 
Parameter list: 

A(y) 

A(x) 

A(Target) 


Called by: Compiled code 


IHE ATW 


Calls: IHEATS, IHEHTS 


Entry point IHEATWN 
Function: 


 ATAN(z), where z is complex short 
floating-point. 
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Linkage: 


RA: A( Parameter list) 
Parameter list: 

A(z) 

A(Target) 


Called bys Compiled code 


Entry point IHEATWH 





Calls: IHEATS2, IHEHTS 
Function: 


ATANH(z), where z is complex short 
floating-point. 


Linkage: 
RAs A(Parameter list) 
Parameter list: 
A(z) 
A(Target) 
Called by: Compiled code 
IHEATZ 
Calis: IHEATL, IHEHTL 
Entry point IHEATZN 
Calls: IHEATL2, IHEHTL 


Functions: 


ATAN(z), where z is complex long 
floating-point. 


Linkage: 
RA: A (Parameter list) 
Parameter list: 
A (2) 
A (Target) 
Called by: Compiled code 
Entry point IHEATZH 
Calls: IHEATL2, IHEHETL 


Function: 


ATANH (z), when z is complex long 
floating-point. 


Linkage: 
RA: A (Parameter list) 
Parameter list: 
A (z) 
A (Target) 


Called by: Compiled code 


IHEBEG 
Calls: 


Supervisor (LINK, GETMAIN, FREEMAIN), 
IHETOM 


Entry point IHEBEGA 
Function: 
Links to IHETOM to issue a WTO macro 
instruction if the PRV is longer than 
4096 bytes. 
Linkages: None 
Called by: IHESAP, IHETSA 
Entry point IHEBEGN 
Functions: 
Links to IHETOM to issue a WTO macro 
instruction if the program does not 
have a main procedure. 
Linkage: None 
Called by: IHESAP, IHETSA, IHEMAIN 
IHEBSA 
Entry point: IHEBSAO 


Function: 


AND operator (&) for two byte-aligned bit 
strings. 


Linkage: 
RA: A(SDV of first operand) 
RB: A(SDV of second operand) 
RC: A(SDV of target field) 
Called by: Compiled code 
IHEBSC 
Entry point: IHEBSCO 
Function: 
To compare two byte-aligned bit strings. 
Linkage: 
RA: A(SDV of first operand) 
RB: A(SDV of second operand) 
RC: A(Target) 
Called by: Compiled code 
IHEBSD 


Entry point: IHEBSDO 


Function: 
TO compare two bit strings with any 
alignment. 
Linkage: 
RA: A(SDV of first operand) 
RB: A(SDV of second operand) 
RC: A(Target) 
Called by: Compiled code 
IHEBSF 
Entry points: IHEBSFO 


Function: 


BOOL (Bit string, bit string, string n, 
Na Ng n,). 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(SDV of first source string) 
A(SDV of second source string) 
A(Fullword containing bit pattern n, no 
n3 n, right justified) 
A(SDV of target field) 
Called by: Compiled code 
IHEBSI 
Entry point: IHEBSIO 
Function: 
INDEX (Bit string, bit string). 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(SDV of first source string) 
A(SDV of second source string) 
A(Target field) 
Called by: Compiled code 
IHEBSK 
Entry point IHEBSKA 
Functions: 


To assign a bit string to a target 
field. 


Linkages 


RA: A(SDV of source string) 
RB: A(SDV of target field) 


Called bys Compiled code 
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Entry point IHEBSKK 


Function: 


Concatenate operator (||) for bit 
strings. 
Linkage: 
RA: A(SDV of first operand) 
RB: A(SDV of second operand) 
RC: A(SDV of target field) 
Called by: Compiled code, IHESTGA 
Entry point IHEBSKR 
Function: REPEAT (Bit string,n). 
Linkages: 
RA: A(SDV of source string) 
RBs: A(n) 
RC: A(SDV of target field) 
Called by: Compiled code 
IHEBSM 
Entry point IHEBSMF 


Function: 


To assign a byte-aligned bit string to 
a byte-aligned fixed-length target. 


Linkage: 


RA: A(SDV of source string) 
RB: A(SDV of target field) 


Called by: Compiled code 
Entry point IHEBSMV 
Functions: 


To assign a byte-aligned bit string to 
a byte-aligned VARYING target. 


Linkage: As for IHEBSMF 
Called by: Compiled code 
Entry point IHEBSMZ 
Function: 
To £111 out a bit string from its 
current length to its maximum length 
with zero bits. 


Linkage: RAs: A(SDV) 


Called by: Compiled code 
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IHEBSN 
Entry point: IHEBSNO 
Function: 


NOT operator (,) for a byte-aligned bit 
string. 


Linkage: 


RA: A(SDV of operand) 
RB: A(SDV of target field) 


Called by: Compiled code 
IHEBSO 

Entry point: IHEBSOO 
Function: 


OR operator (|) for two byte-aligned bit 
strings. 


Linkage: 


RA: A(SDV of first operand) 
RB: A(SDV of second operand) 
RC: A(SDV of target field) 


Called by: Compiled code 


IHEBSS 


Entry point IHEESS2 


Function: 


To produce an SDV describing the 
pseudo-variable or function SUBSTR (Bit 
String, i). 


Linkage: 


RA: A( Parameter list) 
Parameter lists: 
A(SDV of source string) 
A(i) 
Dummy argument 
A(Field for target SDV) 


Called bys: Compiled code 
Entry point IHEBSS3 

Function: 
To produce an SDV describing the 
pseudo-variable or function SUBSTR (Bit 
string, i, j).- 

Linkages 
RA: A(Parameter list) 
Parameter list: 


A(SDV of source string) 
A(i) 


A(j) 
A(Field for target SDV) 

Called by: Compiled code 
IHEBST 

Calls: IHEBSF, IHEBSI, IHEBSS 
Entry point: IHEBSTA 
Function: Translate bit string 

Linkage: 

RA: A(Parameter list) 

Parameter list: 
A(SOURCE/TARGET SDV) 
A(REPLACEMENT SDV) 
A(POSITIONAL SDV) 

Called by: Compiled code. 
IHEBSV 

Calls: 

Entry point: IHEBSVA 
Function: Verify bit string 

Linkage: 

RA: A(Parameter list) 
Parameter list: 

A(E1 SDV) 

A(E2 SDV) 

A(Result field) 

Called bys Compiled code. 
IHECFA 
Entry point: IHECFAA 
Function: 

ONLOC: Locates the BCD name of the 

procedure that contains the PL/I 

interrupt that caused entry into the 
current on-unit. If ONLOC is specified 
outside an on-unit, a null string is 
returned. 

Linkage: 


RA: A(Parameter list) 
Parameter list: A(Target SDV) 


Called by: Compiled code 
IHECFB 
Entry points IHECFBA 
Function: 


ONCODE: Returns a value corresponding to 
the condition which caused the interrupt. 


If specified outside an on-unit, a unique 
code (0) is returned. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(4-byte word-aligned target) 


Called by: Compiled code 
LHECFC 

Entry points: IHECFCA 
Function: 


ONCOUNT: Returns a value equal to the 
number of PL/I conditions and program 
exceptions, including the current one, 
that have yet to be processed. A zero 
value is returned if: 


1. ONCOUNT is used outside an ON unit, 
or 


2. ONCOUNT is used in an ON unit entered 
because of a precise interrupt or a 
single imprecise interrupt | 


(This built-in function is used in 
connection with the Model 91 and 195 
option) 


Linkage: 


RA: A( Parameter list) 
Parameter list: 
A(4=-byte word-aligned target) 


Called by: Compiled code 
IHECKP 


Calls: Supervisor 


Entry point: IHECKPS 


Functions: 


Requests the control program checkpoint 
facility to save main storage areas and 
control information so that the job 
step may be restarted from the check- 
point. 


Linkages: 
IHECKPS: 
RAs A(Parameter list) 
Parameter list: 
A(ddname SDV) 
A(checkid SDV) 
A(data set organization SDV) 
A(Return code field) 


Called by: 


Compiled code (CALL IHECKPS statement) 
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on point: IHECKPT | 

Function: As for IHECKPS 

Linkage: none 

Called by: compiled code (CALL IHECKPT 
statement) 

IHECLT 


Calis: 


IHESA, Supervisor (CLOSE, DCBD, DELETE, 
FREEMAIN, FREEPOOL, RETURN) 


Entry point IHECLTA 


Function: 


Close files: 

1. Free FCB. 

2. Set file register to zero. 

3. Remove file from IHEQFOP chain. 


4. Delete interface modules loaded for 
record-oriented I/0. 


5. Purge outstanding I/O events, 
setting event variables complete, 
abnormal, and inactive. 


Linkage: 


RA: A(Parameter list) 
Parameter lists 
A(CLOSE parameter list) 
A(Private adcons) 


CLOSE parameter list: 
A(DCLCB, ) 
(Reserved) 
(Reserved) 


A(DCLCBn) 

(Reserved) 

(Reserved) 

(High-order byte of last argument 
indicates end of parameter list) 


Called by: IHEOCL 
Entry point IHECLTB 
Function: 
To close all files when a task is 


terminated. 
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Linkages: 
RA: A( Parameter list) 
Parameter list: 
F(number of files to be closed#&) 


A(Adcon list) 
A(ist FCB) 


ACnth FCB) 
(High-order byte of last argument 
indicates end of parameter list.) 
Called by: IHEOCL 
IHECNT 
Entry point IHECNTA 


Function: 


Returns count of scalar items 
transmitted on last I/O operation. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A (DCLCB) 
A(Fullword) 
Called by: Compiled code 
Entry point IHECNTB 
Function: 
Returns current line number (LINENO). 
Linkage: As for IHECNTA 
Called by: Compiled code 
IHECSC 
Entry point: IHECSCO 
Function: 
To compare two character strings. 
Linkage: 
RA: A(SDV of first operand) 
RB: A(SDV of second operand) 
RC: A(Target) 
Called by: Compiled code 
IHECSI 
Entry point: IHECSIO 


Function: 


INDEX (Character string, character 
string). 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(SDV of first source string) 
A(SDV of second source string) 
A(Target field) 


Called by: Compiled code 


IHECSK 
Entry point IHECSKK 
Function: 
Concatenate operator (||) for character 
strings. 
Linkage: 
RA: A(SDV of first operand) 
RB: A(SDV of second operand) 
RC: A(SDV of target field) 
Called by: Compiled code 
Entry point IHECSKR 
Function: 
REPEAT (Character string, n). 
Linkage: 
RA: A(SDV of source string) 
RB: A(n) 
RC: A(SDV of target field) 
Called by: Compiled code 
IHECSM 
Entry point IHECSMF 


Function: 


To assign a character string to a 
fixed-length target. 


Linkage: 


RA: A(SDV of source string) 
RB: A(SDV of target field) 


Called by: Compiled code 
Entry point IHECSMV 
Function: 
To assign a character string to a 
VARYING target. 
Linkage: As for IHECSMF 


Called by: Compiled code 


Entry point IHECSMB 
Function: 
To fill out a character string from its 
current length to its maximum length 
with blanks. 
Linkage: 
RA: A(CSDV) 
Called by: Compiled code 
Entry point IHECSMH 
Function: HIGH 
Linkage: As for IHECSMB 
Called by: Compiled code 
Entry point IHECSML 
Function: LOW. 
Linkage: As for IHECSMB 


Called by: Compiled code 


THECSS 
Entry point IHECSS2 
Function: 


To produce an SDV describing the 
pseudo-variable or function SUBSTR 
(Character string, i). 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(SDV of source string) 
A(i) 
Dummy argument 
A(Field for target SDV) 


Called by: Compiled code 
Entry point IHECSS3 
Function: 
To produce an SDV describing the 
pseudo-variable or function SUBSTR 
(Character string, i, j). 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(SDV of source string) 
A(i) 


A(4) 
A(Field for target SDV) 
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Called by: Compiled code 


IHECST 
Calls: 
Entry point: IHECSTA 
Function: 
Supplements translate character string 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(SDV of SOURCE/TARGET) 
A(SDV of REPLACEMENT) 
A(SDV of POSITIONAL) 
A(Translate table) 
Called by: Compiled code. 
IHECSV 
Calls: 
Entry point: IHECSVA 


Function: Supplements verify character 
string 


Linkage: RA:A(Parameter list) 
Parameter list: 
A(E1 SDV) 
A(E2 SDV) 
A(Translate table) 
A(Result field) 
Called by: Compiled code. 
IHECTT 
Calls: 


IHETSA, Supervisor (CLOSE, DCBD, DELETE, 
DEQ, FREEMAIN, FREEPOOL, RETURN) 


Entry point IHECTTA 
Function: 


Close files in a multitasking 
environment: 


1. Free FCB. 
2. Set file register to zero. 
3. Remove file from IHEQFOP chain. 


4. Delete interface modules loaded for 
record-oriented I/O. 


5. Purge outstanding I/O events, 


setting event variables complete, 
normal, and inactive. 
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(i) Check that the file is in 
the IHEQFOP chain for the 
current task. 


(ii) Free IOCBs, setting 
associated EVENT variables 
complete, abnormal, and 


inactive. 


Set EVENT variables in TEVT 
chain complete, abnormal, 
and inactive. 


(111) 


For REGIONAL EXCLUSIVE 
files, or INDEXED EXCLUSIVE 
files with unblocked 
records, dequeue locked 
records and free EXCLUSIVE 
blocks in the TXLV chain. 


(iv) 


(v) For INDEXED EXCLUSIVE files 
with blocked records, unlock 
the files. 


Linkage: 


RA: A( Parameter list) 
Parameter list: 
A(CLOSE parameter list) 
A(Private adcons) 


CLOSE parameter list: 
A (DCLCB, ) 
ACIDENT SDV,)/0 
ACIDENT DED,) 70 


e 


A(DCLCBy) 

ACCIDENT SDVpy) 70 

A(IDENT DED,) /0 

(High-order byte of last argument 
indicates end of parameter list) 


Called by: IHEOCT 


Entry point IHECTTB 


Function: 


To close all files when a task is 
terminated. 


Linkage: 


RA: A( Parameter list) 

Parameter list: 
F(number of files to be closed#4) 
A(Adcon list) 
A(C1ist FCB) 


A(nth FCB) 
(High-order byte of last argument 
indicates end of parameter list) 


Called by: IHEOCT 


Entry point IHECTTC 


Functions 


Implicit close for tasks detached at 
undetermined points. 


Linkage: as for IHECTTB 


Called by: IHEOCT 


IHEDBN 
Calls: IHEDMA, IHEUPA, IHEUPB 
Entry point: IHEDBNA 
Function: 
To convert a bit string to an arithmetic 
target with a specified base, scale, 
mode, and precision. 
Linkage: 
RA: A(Source SDV) 
RB: A(Source DED) 
RC: A(Target) 
RD: A(Target DED) 
Called by: 
Compiled code, IHEDOA, IHEDOE, IHEDOM 
IHEDCN 
Calls: IHEDMA, IHEUPA, IHEUPB, IHEVOB 
Entry point IHEDCNA 
Function: 
To convert a character string 
containing a valid arithmetic constant 
or complex expression to an arithmetic 
target with specified base, scale, 
mode, and precision. The ONSOURCE 
address is stored. 
. Linkage: 
RA: A(Source SDV) 
RB: A(Source DED) 
RC: A(Target) 
RD: A(Target DED) 
WOFD: A(Source SDV) 
Called by: 
Compiled code, IHEDIB, IHEDOA, IHEDOE 
Entry point IHEDCNB 


Function: 


As for IHEDCNA, but the ONSOURCE 
address is not stored. 


Linkage: 
As for IHEDCNA, but without WOFD 


Called by: As for IHEDCNA 


IHEDDI 


Calls: 
IHEDDJ, IHEIOF, IHELDI, IHESAP, IHETSA 
Ent oint IHEDDIA 
Function: 
To read data from an input stream and 
assign it to internal variables 
according to symbol table information 
conventions. Restrictive data list. 
Linkage: 
RA: A(Parameter list) 


Parameter list: 
A(Symbol table,) 


A(Symbol tableny) 
(High-order byte of last argument 
indicates end of parameter list.) 
Called by: Compiled code 
Entry point IHEDDIB 
Function: 
As for IHEDDIA, but no data list. 
Linkage: 


RA: A(Parameter list) 
Parameter list: A(Symbol table chain) 


Called by: Compiled code 

IHEDDJ 

Entry point: IHEDDJA 

Function: 
To compute the address of an array 
element from source subscripts and an 
ADV. 

Linkage: 
RA: A(CADV) 
RB: A(DED) 
RC: A(Field for element address) 
RD: A(Symbol table entry, 2nd part) 
RE: A(SDV for subscripts) 


Called by: IHEDDIA 
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LTHEDDO 
Calls: 


LHEDDP, IHEIOF, IHELDO, IHEPRT 


Entry point IHEDDOA 
Function: 


To convert data according to 
data-directed output conventions and to 
write it onto an output stream. For 
scalar variables and whole arrays. 


Linkage: 


RAs A(Parameter list) 
Parameter list: 
A(Symbol table entry,) 


A(Symbol table entryn) 
(High-order byte of last argument 
indicates end of parameter list.) 


Called by: Compiled code 


Entry point IHEDDOB 


Functions: 


As for IHEDDOA but for array variable 
elements. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(Symbol table entry,) 
A(Element address, ) 


A(Symbol table entryn) 

A(Element addressny) 

(High-order byte of last argument 
indicates end of parameter list.) 


Called by: Compiled code 


Entry point ITHEDDOC 
Function: 


To terminate data-directed transmiss- 
ion. 


Linkage: None 


Called by: Compiled code 
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Entry point IHEDDOD 


Function: 


As for IHEDDOA, but used to support the 
CHECK condition. | 


Linkages: 
RA: A(Parameter list) 
Parameter list: 
A(Symbol table entry) 
ACElement address) 
Called by: IHEERR, IHESAPA 
Entry point IHEDDOE 
Function: 
In the absence of a data list, to 
convert all data known within a block 
according to data-directed output 
conventions and to write it onto an 
output stream. 
Linkages 
RA: A(Parameter list) 
Parameter list: 
A(First symbol table entry) 
Called by: Compiled code 
IHEDDP 
Entry point IHEDDPA 
Function: 
TO prepare an array for subscript 
output operation, and to address the 
first element. 
Linkage: 
RA: A(Field for A(VDA)) 
RBs: A(CFCB) 
RC: A(Symbol table entry, 2nd part) 
Called by: IHEDDO, IHEDDT 
Entr Oint IHEDDPB 
Function: To perform subscript output. 
Linkage: 


RAs: A(Parameter list) 
Parameter list: A(VDA) 


Called by: IHEDDO, IHEDDT 
Entry point IHEDDPC 
Function: 


To address the next element. 


Linkage: 


RA: A(Parameter list) 
Parameter list: A(VDA) 
Return codes: 
BR=0;: Another element 
BR=4;: End of array 


Called ky: IHEDDO, IHEDDT 


Entry point IHEDDPD 


Function: 
To prepare an array for subscript 
output operation for a given element. 
Linkage: 


RA: A(Field for A(VDA) ) 
RB: A(FCB) 


RC: A(Symbol table entry, 2nd part) 
RD: A(Element) 
Called by: THEDDO, IHEDDT 
IHEDDT 
Calls: 
Supervisor (DEQ,ENQ), IHEDDP, IHEIOF, 


IHELDO, IHEPTT 


Entry point IHEDDTA 


Function: 


To convert data according to 
data-directed output conventions and to 
write it onto an output stream. For 
scalar variables and whole arrays ina 
multitasking environment. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(Symbol table entry,) 


A(Symbol table entryn) 
(High-order byte of last argument 
indicates end of parameter list) 


Called by: Compiled code 
Entry point IHEDDTB 
Function: 


As for IHEDDTA but for array variable 
elements. 


Linkage: 


RA: A( Parameter list) 
Parameter list: 
A(Symbol table entry,) 
A(CElement address,) 


A(Symbol table entryn) 

A(Element addressy) 

(High-order byte of last argument 
indicates end of parameter list) 


Called by: Compiled code 


Entr Oint IHEDDTC 


Function: 


To terminate data-directed transmission 
in a multitasking environment. 


Linkage: None 


Called by: Compiled code 


Entry point IHEDDTD 


Function: 


As for IHEDDTA, but used to support the 
CHECK condition in a multitasking 
environment. 


Linkage: 


RA: A( Parameter list) 

Parameter list: 
A(Symbol table entry) 
A(Element address) 


Called by: IHEERR, IHETSA 


Entry point IHEDDTE 


Function: 


In the absence of a data list, to convert 
all data known within a block according 
to data-directed output conventions and 
to write it onto an output stream ina 
multitasking environment. 


Linkage: 
RA: A( Parameter list) 


Parameter list: 
A(First symbol table entry) 


Called by: Compiled code, IHEDDTA 
IHEDIA 
Calls: 
IHEDMA, IHEDNB, IHEDNC, IHEIOD, IHEUPA, 
IHEUPB, IHEVCA, IHEVQB, IHEVSA, IHEVSC 
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Entry point IHEDIAA 

Function: 
To direct the conversion of F format 
data to an internal data type. 

Linkage: 
RA: A(Target or target dope vector) 
RB: A(Target DED) 
RC: A(FED) 


Called by: Compiled code, IHEDIM 


Entry point IHEDIAB 


Function: 
To direct the conversion of E format 
data to an internal data type. 
Linkage: As for IHEDIAA 
Called by: As for IHEDIAA 
IHEDIE 
Calls: 


IHEDCN, IHEIOD, IHEKCD, IHEVSC, IHEVSD, 
IHEVSE 


Entry point IHEDIBA 
Function: 


To direct the conversion of A format 
data to an internal data type. 


Linkage: 
RA: A(Target or target dope vector) 
RB: A(Target DED) 
RC: A(FED) 
Called by: Compiled code 
Entry point IHEDIBB 
Function: 
To direct the conversion of pictured 
character string data to an internal 
data type. 
Linkage: As for IHEDIBA 
Called by: Compiled code 
IHEDID 
Calls: 
IHEDBN, IHEDMA, IHEIOD, IHEUPA, IHEUPB, 
IHEVSC, IHEVSD, IHEVSE 
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Entry point: IHEDIDA 
Function: 
To direct the conversion of external B 
format data to an internal data type. 
Linkage: 
RA: A(Target or target dope vector) 
RB: A(Target DED) 
RC: A(FED) 


Called by: Compiled code 


IHEDIE 
Calls: 
IHEDMA, IHEDMB, IHEDMC, IHEIOD, IHEKCA, 


IHEKCB, IHEUPA, IHEUPB, IHEVSC, IHEVSD, 
IHEVSE 


Entry point: IHEDIEA 


Function: 
To direct the conversion of external data 
with a numeric picture format to an 
internal data type. 

Linkage: 
RA: A(Target or target dope vector) 
RB: A(Target DED) 
RC: A(FED) 


Called by: Compiled code, IHEDIM 


IHEDIL 
Entry point IHEDILA 
Function: 
To set up appropriate error handling 
when no width specification for A 
format input is given. 
Linkage: None 
Called by: Compiled code 
Entry point IHEDILB 
Function: 
As for IHEDILA, but B format 
Linkage: None 


Called by: Compiled code 


IHEDIM 
Calls: 


IHEDIA, IHEDIE, 
IHEVCS 


IHEIOD, IHEKCA, IHEVCA, 


Entry point: IHEDIMA 
Function: 


To direct the conversion of external data 
with C format to an internal data type. 


Linkage: 
RA: A(Target or target dope vector) 
RB: A(Target DED) 
RC: A(Real format director) 
RD: A(Real FED) 
RE: A(Imaginary format director) 
RF: A(Imaginary FED) 

Called by: Compiled code 

IHEDMA 

Transfers control to: 


IHEVFD, IHEVFE, IHEVKB, 
IHEVPF, IHEVPG, IHEVPH 


IHEVKC, IHEVPE, 


Entry point: IHEDMAA 
Function: 
To set up the intermodular flow to effect 
conversion from one arithmetic data type 
to another. 
Linkage: 
RA: A(Source) 
RB: A(Source DED) 
RC: A(Target) 
RD: A(Target DED) 
Called by: 


Compiled code, I/O directors, IHEDBN, 


IHEDCN, 
IHEPDX, 
IHESSF, 
IHEVFEB, 
IHEVPD, 


IHEDNB, 
IHEPSF, 
IHESSX, 
IHEVFC, 
IHEVEF, 


IHEDNC, 
IHEPSX, 
IHEUPB, 
IHEVPA, 
IHEVKG, 


IHELDI, 
IHESMF, 
IHEVCS, 
IHEVPB, 
IHEYGF, 


IHEPDF, 
IHESMX, 
IHEVFA, 
IHEVPC, 
IHEYGX 


IHEDNB 

Calls: IHEDMA, IHEVSA 

Entry point: IHEDNBA 

Function: 
To convert an arithmetic source with 
specified base, scale, mode, and 


precision to a fixed-length bit string or 
a VARYING bit string of specified length. 


Linkage: 


RA: A(Source) 

RB: A(Source DED) 
RC: A(Target SDV) 
RD: A(Target DED) 


Called by: 


Compiled code, IHEDI, IHEDIE, IHEDOD, 
IHEVCS 
IHEDNC 
Calls: 
IHEDMA, IHEUPA, IHEVOC, IHEVSC, IHEVSE 
Entry point: IHEDNCA 


Function: 


To convert an arithmetic source of 
specified base, scale, mode, and 
precision to a character string or a 
pictured character string. 


Linkage: 
RA: A(Source) 
RB: A(Source DED) 
RC: A(Target SDV) 
RD: A(Target DED) 


Called by: 


Compiled code, IHEDIA, IHEDIE, IHEDOA, 
IHEDOB, IHELDI, IHELDO, IHEVCS 

LHEDOA 

Calls: 
IHEDBN, IHEDCN, IHEDMA, IHEIOD, IHEVQC 


Entry point IHEDOAA 
Function: 


To direct the conversion of internal 
data to external F format. 


Linkage: 
RA: A(Source or source dope vector) 
RB: A(Source DED) 
RC: A(FED) 

Called by: Compiled code 

Entry point IHEDOAB 

Function: 

To direct the conversion of internal 


data to external E format. 
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Linkage: As for IHEDOAA 
Called by: As for IHEDOAA 
- IHEDOB 

Calls: 


IHEDNC, IHEIOD, IHEVSB, IHEVSC, IHEVSE, 
IHEVSF 


Entry point IHEDOBA 


Function: 


To direct the conversion of internal 
data to external A(w) format. 


Linkage: 
RA: A(Source or source dope vector) 
RB: A(Source DED) 
RC: A(FED) 


Called by: Compiled code 


Entry point IHEDOBB 


Function: 


To direct the conversion of internal 
data to external A format. 


Linkage: 


RA: A(Source or source dope vector) 
RB: A(Source DED) 


Called by: Compiled code 


Entry point IHEDOBC 
Function: 
To direct the conversion of internal 
data to external pictured character 
format. 
Linkage: As for IHEDOBA 
Called by: Compiled code 
IHEDOD 
Calls: IHEDNB, IHEIOD, IHEVSB, IHEVSC 
Entry point IHEDODA 
Function: 
To direct the conversion of internal 


data to external B(w) format. 
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Linkage: 
RA: A(Source or source dope vector) 
RB: A(Source DED) 
RC: A(FED) 


Called by: Compiled code 


Entry point IHEDODB 
Function: 


To direct the conversion of internal 
Gata to external B format. 


Linkage: 


RA: A(Source or source dope vector) 
RB: A(Source DED) 


Called by: Compiled code 
IHEDOE 
Calls: 
IHEDBN, IHEDCN, IHEDMA, IHEIOD, IHEVSB 
Entry point: IHEDOEA 
Function: 
To direct the conversion of internal data 
to external data with a numeric picture 
format. 
Linkage: 
RA: A(Source or source dope vector) 
RB: A(Source DED) 
RC: A(FED) 
Called by: Compiled code, IHEDOM 
IHEDOM 
Calls: 
IHEDBN, IHEUPA, IHEUPB, IHEVCA, IHEVCS 
Entry point: IHEDOMA 


Function: 


To direct the conversion of an internal 
data type to external C format data. 


Linkage: 


RA: A(Source or source dope vector) 
RB: A(Source DED) 

RC: A(Real format director) 

RD: A(Real FED) 

RE: A(Imaginary format director) 
RF: A(Imaginary FED) 


Called by: Compiled code 


IHEDSP 


Calls: Supervisor (WAIT, WTO, WTOR, 
GETMAIN, POST, FREEMAIN, CHAP) 


Entry point: IHEDSPA 


‘Function: 


To write a message on the operator's 
console, with or without a reply. The 
EVENT option can be used for a message 
with a reply. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(SDV for message) 
A(SDV for reply) 
A(Event variable) 
(The parameter list is either one, 
two, or three elements long, 
depending on the use of the REPLY ana 
EVENT options. The high-order byte 
of the last argument indicates the 
end of the parameter list.) 


Called by: Compiled code 


IHEDUM 
Calls: 


Supervisor (ABEND, LINK, POST, SNAP, 
WAIT), IHEQMA, IHESAFQ IHETSA, IHEZZC 


Entry point IHEDUMC 
Function: 


Dump current task and then continue 
execution. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
F(Number in range 0 through 255) 


Called by: Compiled code (CALL IHEDUMC 
statement). 


Entry point IHEDUMJ 
Function: 


Dump all tasks and then continue 
execution. 


Linkage: As IHEDUMC 


Called by: Compiled code (CALL IHEDUMJ 
statement) 


Entry point IHEDUMP 
Function: 
Dump all tasks and terminate major 
task. 


Linkage: As IHEDUMC 


Called by: Compiled code (CALL IHEDUMP 
statement) 


Entry point IHEDUMT 
Function: 


Dump current task and then terminate 
it. 


Linkage: As IHEDUMC 


Called by: Compiled code (CALL IHEDUMT 
statement) 


IHEDVU 


Entry point: IHEDVUO 


Function: 


DIVIDE(w,Z,p.q), where w and z are 
complex fixed-point binary, and (p,q) is 
the target precision. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 

A(w) 

A(DED for w) 

A(z) 

A(DED for z) 

A(Target) 

A(DED for target) 


Called by : Compiled code 
IHEDVV 
Calls: IBEAPD 
Entry point: IHEDVVO 
Function: 
DIVIDE (w,Z,p,q), where w and z are 


complex fixed-point decimal, and (p,q) is 
the target precision. 
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Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(w) : 
A(DED for w) 
A(z) 
A(DED for z) 
A (Target) 
A(DED for target) 


Called by: Compiled code 


IHEDZW 


Entry point: IHEDZWO 


Function: 
Z3/Z2, where Zz, and Z2 are complex short 
floating-point. 
Linkage: 
RA: A(z4) 
RB: A(z) 
RC: A(Target) 
Called by: Compiled code 
IHEDZ2Z 
Entry point: IHEDZZ0 


Function: 


Z1/Z2, Where z, and Zz are complex long 
floating-point. 


Linkage: 
RA: A(z4) 
RB: A(zo2) 
RC: A(Target) 
Called by: Compiled code 
IHEEFL 
Calls: IHEEXL 
Entry point IHEEFLF 
Function: 
ERF(x), where x is real long 
floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A(Target) 


Called by: Compiled code | 
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Entry point IHEEFLC 


Function: 


ERFC (x), where x is real long 
floating-point. 


Linkage: As for IHEEFLF 


Called by: Compiled code 


IHEEFS 
Calls: IHEEXS 


Entry point IHEEFSF 


Functions: 


ERF (x), where x is real short 
floating-point. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A(Target) 


Called by: Compiled code 


Entry point IHEEFSC 


Function: 


ERFC(x), where x is real short 
floating-point. 


Linkage: As for IHEEFSF 
Called by: Compiled code 

IHEERD 

Function: 
Non-resident part of the error-handling 
routines. It contains the 
data-processing error messages, and when 
required is dynamically loaded from 
IHEESM (Versions 3 and 4). 

IHEERE 

Function: 
Non-resident part of the error-handling 
routines. It contains the input/output 
error messages, and when required is 
dynamically loaded from IHEESM (Versions 
3 and 4). 

IHEERI 


Function: 


Non-resident part of the error-handling 
routines. It contains the remaining 


error messages, that is, those not 
contained in IHEERD, IHEERE, IHEERO and 
IHEERP, and when required is dynamically 
loaded from IHEESM (Versions 3 and 4). 


ITHEERN 
Function: 


Non-resident part of the error package. 
It contains the error messages, and is 
dynamically loaded as required by IHEERR 
(Version 1) or IHEESS (Version 2). 


IHEERO 
Function: 


Non-resident part of the error-handling 
routines. It contains the error 
messages, and when required is 
dynamically loaded from IHEESM (Versions 
3 and 4). 


IHEERP 
Function: 


Non-resident part of the error-handling 
routines. It contains the error 
messages, and when required is 
dynamically loaded from IHEESM (Versions 
3 and 4). 


IHEERR 
Calls: 


Supervisor (LINK, SPIE), IHEDDO, IHEDDT, 
IHEERS (Version 1), IHEESM, IHEESS . 
(Version 2), IHEM91, IHEPRT, IHEPTT, 
IHESAP, IHETER, IHETSA 

IHEERRE calls: LINK, ABEND with DUMP and 
STEP options 


Entry point IHEERRA (Program Interrupt): 
Function: 


To determine the identity of the error or 
condition that has been raised, and to 
determine what action must be taken on 
account of it. Several Courses of action 
are possible, including combinations of: 


(1) Entry into an on-unit 

(2) SNAP 

(3) No action - return to program 

(4) Print error message and terminate 

(5) Print error message and continue 

(6) Set standard results into float 
registers 

(7) Branches to IHEM91 for imprecise 
interrrupts. 


Linkage: None 


Called by: Supervisor 


Entry point IHEERRB (ON Conditions): 
Function: As for IHEERRA. 
Linkage: 


RA: A(DCLCB) (for I/0 conditions) 
IHEQERR: Error code 


Called by: Compiled code, library modules 


Entry point IHEERRC (Non-ON errors): 
Function: As for IHEERRA. 


Linkages 


RA: A(Two-byte error code) 
A(Four-byte code if source program 
error) 


Called by: Compiled code, library modules 


Entry point IHEERRD (CHECK, CONDITION) : 
Functions: As for IHEERRA. 


Linkage: 


RA: A( Parameter list) 
Parameter list: 
One-byte error code 
Three-byte A(X) 
Xs: Symbol table 


X: Symbol table (CHECK variable), or 
Symbol length and name(CHECK label), 
or 
Identifying CSECT (CONDITION) 


Called by: Compiled code 
Entry point IHEERRE 
Function: 
To accept control when a program 
interrupt occurs in IHEERR or in 
modules that IHEERR calls or links to; 
to link to IHETOM to write a disaster 
message on the console; to terminate 
the program and to provide an operating 
system ABDUMP. 
Linkage: None 
Called by: Supervisor 
LHEERS 
Entry point: IHEERSA 
Function: 
SNAP: To determine and record the 
location of the point of interrupt and to 


print the procedure trace-back 
information associated with it. 
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Linkage: 


RA: A( Third word of a library VDA to 
be used as a save area and message 
buffer): words 21 to 23 of the VDA 
are used to pass the following 
parameters: 

21: A(Interrupt VDA)/0 
22: A(PRINT routine) 
23: A(Current DSA) 


Called by: IHEERR (Version 1) 


IHEERT 


Function: 


Non-resident part of the error-handling 
routines. It contains the multitasking 
error messages, and is dynamically loaded 
when required from IHEESM or IHETEX 
(Version 4). 


IH EESM 
Calls: 
Supervisor (DELETE, DEQ, ENQ, LOAD), 


IHEERD, IHEERE, IHEERI, IHEERO, IHEERP, 
IHEERT, IHEPRT, IHEPTT, IHESAP, IHETSA 


Entry point IHEESMA 


Function: 


To print out SNAP and system action 
messages. 


Linkage: 


RA: A(First word of a library VDA to be 
used as a save area and message 
buffer) 


RH: A(Current DSA) 


Also passed are: 
AC(IHEPTTB) or A(CIHEPRTB): current LWE 
xcuerse or A(IHESADE): current LWE 
a nee or A(IHESAFD): current LWE 
eee PRVs current LWE+102 


Called by: IHEERR (Versions 3 and 4) 
Entry point IHEESMB 
Function: 
To print CHECK (label) system action 


messages. 
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Linkage: 


RA: A(Label) 
RB: A(Length of label) 


Also passed: 
ACIHEPTTB) or ACIHEPRTB): Current LWE 
+ 124 


Called by: IHEERR (Versions 3 and 4) 


LHEESS 





Calls: IHEERN, IHEPRT, IHESAP, IHETSA 


Entry point IHEESSA 


Function: 


To print out SNAP and system action 
messages. 


Linkage: 


RA: A(First word of a library VDA to be 
used as a save area and message 
buffer) 


Also passed are: 


A(Interrupt VDA/0): current LWE + 96 
A(Current DSA): current LWE + 100 
ACIHESADE) : current LWE + 104 
A(IHESAFE) : current LWE + 108 
ACIHEPRT) : current LWE + 112 


Called by: IHEERR (Version 2) 
Entry point IHEESSB 
Function: 


fo print CHECK (label) system action 
messages. 


Linkage: 


RA: A(Label) 
A(Length of label) 


Also passed: 
A(CIHEPRTB): current LWE + 112 
Called by: IHEERR (Version 2) 
IHEEXL 
Entry point: IHEEXLO 
Function: 


EXP(x), where x is real long 
floating-point. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A (Target) 
Called by: 
Compiled code, IHEEFL, IHEEXZ, IHESHL, 
IHESNZ, IHETHL, IHEXXL 
IHEEXS 


Entry point: IHEEXS0 


Function: 
EXP(x), where x is real short 
floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A (Target) 
Called by: 


Compiled code, IHEEFS, IHEEXW, IHESHS, 
IHESNW, IHETHS, IHEXXS 


IHEEXW 

Calls: IHEEXS, IHESNS 
Entry point: IHEEXWO 
Function: 


EXP(z), where z is complex short 
floating-point. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(z) 
A (Target) 
Called by: Compiled code, IHEXXW 
IHEEXZ 
Calls: IHEEXL, IHESNL 
Entry point: IHEEXZ0 


Function: 


EXP(z), where z is complex long 
floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 

A(z) 

A(Target) 


Called by: Compiled code, IHEXXZ 


IHEHTL 


Calls: IHELNL 
Entry point: IHEHTLO 


Function: 
ATANH(x), where x is real long 
floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A(Target) 


Called by: Compiled code, IHEATZ 


IHEHRTS 


Calls: IHELNS 


Entry point: IHEHTSO 


Function: 
ATANH (x), where x is real short 
floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A(Target) 


Called by: Compiled code, IHEATW 


IHEIBT 

This module is used in a multitasking 
environment and is equivalent to module 
IHEIOB in a non-multitasking environment. 
Calls: 


Supervisor (DEQ,ENQ), IHEIOP, IHEOCT 
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Entry point IHEIBTA 


Function: 


To initialize the PUT operation, and to 
check the file status, ina 
multitasking environment: 


1. Open 

2. Transmit error 

3. Invalid 
Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(DCLCB) 
A(Aknormal return) 


Called ky: Compiled code 


Entry point IHEIBTB 


Function: 


To initialize PUT, and perform PAGE, 
and to check the file status, ina 
multitasking environment: 


1. Open. 
2. Transmit error 
3. Invalid 


Linkage: As for IHEIBTA 


Called by: Compiled code 


Entry point IHEIBTC 


Function: 


To initialize PUT, and perform SKIP, 
and to check the file status, ina 
multitasking environment: 


1. Open 
2. Transmit error 
3. Invalid 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(DCLCB) 
A(Abnormal return) 
A(Expression value) 
Called by: Compiled code 
Entry point IHEIBTD 
Function: 
To initialize PUT, and perform LINE, 


and to check the file status, ina 
multitasking environment: 
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1. Open 

2. Transmit error 

3. Invalid 
Linkage: As for IHEIBTC 


Called by: Compiled code 


Entry point IHEIBTE 


Function: 
To initialize PUT, and perform PAGE and 
LINE, and to check the file status, in 
a multitasking environment: 
1. Open 
2. Transmit error 
3. Invalid 
Linkage: As for IHEIBTC 


Called by: Compiled code 


Entry point IHEIBTT 
Function: 


To terminate the PUT operation, ina 
multitasking environment. 
Linkage: None 


Called by: Compiled code 


IHEIGT 


Entry point: IHEIGTA 


Function: 

As for IHEINT 
IHEINT 

This module is used in a multitasking 
environment and is equivalent to module 
IHEION in a non-multitasking environment. 


Calls: 


Supervisor(CHAP, FREEMAIN, GETMAIN), 
IHEITB, IHEITC, IHEITD, IHEITE, IHEITF, 
IHEIG, IHEIH, IHEIJ, IHEITP, IHEOCT 


Entry point: IHEINTA 


Function: 


To verify a RECORD I/O request and to 
invoke the appropriate data management 
interface module to perform the required 
Operation, in a multitasking environment. 


Linkages: 


RA: A(Parameter list) 

Parameter lists: 
“A (DCLCB) 
ACRDV)/ (IGNORE factor) 
A(EVENT variable)/(0)/A(Error return) 
A (KEY | KEYFROM|KEYTO SDV) /(0) 
A(Request control block) 


Called by: Compiled code 


IHEIOA 


Calls: IHEIOP, IHEOCL, IHEOCT 


Entry point IHEIOAA 


Functions: 


To initialize the GET operation, and to 
check the file status: 


1. Open 


2. Endfile 
3. Invalid 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(DCLCB) 
A(Abnormal return) 


Called by: Compiled code 


Entry point IHEIOAB 
Function: 


To initialize the GET operation, with 
the COPY option, and to check the file 


status: 
1. Open 
2. Endfile 


3. Invalid 
Linkages: As for IHEIOAA 
Called by: Compiled code 

Entry point IHEIOAC 
Function: 


To initialize the GET operation with 
the SKIP option, and to check the file 


status: 
1. Open 
2. Endfile 
3. Invalid 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(DCLCB) 
A(Abnormal return) 
A(Expression value) 
Called by: Compiled code 
Entry point IHEIOAT 
Function: 
To terminate the GET operation. 
Linkage: None 
Called by: Compiled code 
IHEIOB 
Calls: 
IHEIOP, IHEOCL 
Entry point IHEIOBA 
Functions 


To initialize the PUT operation, and to 
check the file status: 


1. Open 
2. Transmit error 
3. Invalid 
Linkages 
RA: A(Parameter list) 
Parameter list: 
A(DCLCB) 
A(Abnormal return) 
Called by: Compiled code 
Entry point IHEIOBB 
Functions: 


To initialize PUT, and perform PAGE, 
and to check the file status: 


1. Open 
2. Transmit error 
3. Invalid 


Linkage: As for IHEIOBA 
Called bys Compiled code 
Entry point IHEIOBC 
Function: 
To initialize PUT, and perform SKIP, 
and to check the file status: 
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1. Open 
- Transmit error 
- Invalid 


Gd NO 


Linkage: _- 
RAs: A(Parameter list) 
Parameter list: 
A(DCLCB) 
A(Abnormal return) 
A(Expression value) 


Called bys: Compiled code 


Entry point IHEIOBD 


Functions 


To initialize PUT, and perform LINE, 
and to check the file status: 


1. Open 

2. Transmit error 

3. Invalid 
Linkage: As for IHEIOBC 


Called by: Compiled code 


Entry point IHEIOBE 


Functions: 


To initialize PUT, and perform PAGE and 
LINE, and to check the file status: 


1. Open 
2. Transmit error 
3. Invalid 
Linkage: As for IHEIOBC 
Called by: Compiled code 
Entry point IHEIOBT 
Function: 
To terminate the PUT operation. 
Linkage: None 
Called by: Compiled code 
IHEIOC 
Calls: IHESAP, IHETSA 
Fntry point IHETOCA 
Function: 
To initialize the GET operation, with 


the STRING option. 
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Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(SDV) 
A (DED) 
Called. by: Compiled code 
Ent Oint IHEIOCB 


Function: 


To initialize the GET operation, with 
the STRING and COPY options. 


Linkage: As for IHEIOCA 
Called by: Compiled code 

Entry point IHEIOCC 
Function: 


To initialize the PUT operation, with 
the STRING option. 


Linkage: As for IHEIOCA 
Called by: Compiled code 

Entry point IHEIOCT 
Functions: 


To terminate the GET or PUT operations, 
with the STRING option. 


Linkage: None 

Called by: Compiled code 
IHEIOD 
Calis: 


IHEIOF, IHESAP, 


LHETSA 


IHEPRT, IHEPTT, 


Entry point IHEIODG 


Functions: 


To obtain the next data field from the 
record buffer(s). 


Linkage: 
Library communication area (WSDV) 
Called by: Format directors, IHEIOX 
Entry point IHEIODP 
Function: 


To obtain space for a data field in the 
record buffer(s). 


Linkage: As for IHEIODG 


Called by: Format directors, IHEIOX 

Entry point IHEIODT 

- Function: 

To terminate the data field request. 

Linkage: As for IHEIODG 
Called by: Format directors 

IHEIOF 

Calls: Data management (QSAM) 

Entry point: IHEIOFA 

Function: 
To obtain logical records via data 
management interface modules, and 
initialize FCB record pointers and 
counters. 

Linkage: RA: A(FCB) 

Called bys 
IHEDDI, IHEDDO, IHEDDT, IHEIOD, IHEIOP, 
IHEIOX, IHELDI, IHELDO, IHEOCL, IHEOCT, 
IHEPRT, IHEPTT 

ILHEIOG 

Entry point: IHEIOGA 


Function: 


As for IHEION 


IHEION 


This module is used ina 
non-multitasking environment and is 
equivalent to module IHEINT in a 
multitasking environment. 


Calls: 

Supervisor (FREEMAIN, GETMAIN), IHEITB, 
IHEITC, IHEITD, IHEITE, IHEITF, IHEITG, 
IHEITP, IHEOCL | 

Entry point: IHEIONA 
Function: 

To verify a RECORD I/O request and to 

invoke the appropriate data management 

interface module to perform the required 
operation, in a non-multitasking 
environment. 

Linkage: 


RA: A(Parameter list) 


Parameter list: 
A(DCLCB) 
A(RDV) / CIGNORE factor) 
A(EVENT variable)/(0)/A(Error return) 
A(KEY| KEYFROM|KEYTO SDV)/(0) 
A(Request control block) 


Called by: Compiled code 


IHEIOP 


Calls: IHEIOF 


Entr Oint IHEIOPA 


Function: PAGE option/format. 
Linkage: No explicit parameters 


Called by: Compiled code, IHEIOB, IHEIBT 


Entry point IHEIOPB 


Function: SKIP option/ format . 
Linkage: 


RA: A( FED) 
FED: Halfword binary integer 


Called by: Compiled code, IHEIOA, IHEIOB, 
IHEIBT 


Entry point IHEIOPC 
Functions: LINE option/format. 
Linkages As for IHEIOPB 
Called by: As for IHEIOPA 
IHEIOX 
Calls: IHEIOD, IHEIOF 
Entry point IHEIOXA 
Function: 
To skip next n characters in record(s). 
Linkages 


RA: A(FED) 
FED: Halfword binary integer 


Called by: Compiled code 
Entry point IHEIOXB 
Functions: 
To place n blanks in record(s). 
Linkage: As for IHEIOXA 


Called by: Compiled code 
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Entry point IHEIOXC 
Function: To position to COLUMN(n). 
Linkage: As for IHEIOXA 
Called by: Compiled code 

IHEITB 

Calls: 


Data management (BSAM), Supervisor (CHAP, 
GETMAIN) 


Entry point: IHEITBA 
Function: 
To provide the interface with BSAM for: 


1. CONSECUTIVE data sets with the 
UNBUFFERED attribute. 


2. REGIONAL data sets, whether or not 
UNBUFFERED, opened for INPUT/UPDATE 


Linkage: 


RA: A(FCB) 
RB: A(Parameter list) 
Parameter list: 
A(DCLCB) . 
A(RDV) /ACIOCB) /A(IGNORE factor)/A(SDV) 
A(Event variable)/ (0) 
A (KEY | KEYFROM|KEYTO SDV)/(0) 
A(Request control block) 


Called by: IHEION, IHEINT 
IHEITC 
Calls: 


Data management (BSAM), Supervisor (CHAP, 
GETMAIN) 


Entry point: IHEITCA 
Function: 


To provide the interface with BSAM for 
creating REGIONAL data sets when opened 
for SEQUENTIAL output. 


Linkage: 


RA: A(FCB) 
RB: A(Parameter list) 
Parameter list: 
A (DCLCB) 
A(CRDV) /ACIOCB) 
A(Event variable)/(0)/A(Abnormal 
return) 
A(KEY|KEYFROM SDV) /(0) 
A(Request control block) 


Called by: IHEION, IHEINT, IHEOCL, IHEOCT 
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IHEITD 
Calls: 


Data management (QISAM), Supervisor 
(GETMAIN), IHESAP, IHETSA 


Entry point: IHEITDA 


Functions: 


To provide the interface with QISAM for 
creating or accessing fixed length record 
INDEXED data sets when opened for 
SEQUENTIAL access. 


Linkage: 


RAs A(FCB) 
RB: A(Parameter list) 
Parameter lists: 
A(DCLCB) 
A(RDV) /A (SDV) 
A(Error return)/(0) 
A(KEY|KEYFROM|KEYTO SDV)/(0) 
A(Request control block) 


Called by: IHEION, IHEINT 
IHEITE 
Calls: 


Data management (BISAM), Supervisor 
(GETMAIN), IHESAP 


Entry point: IHEITEA 
Function: 


To provide the interface with BISAM for 
accessing fixed length record INDEXED 
data sets opened for DIRECT access ina 
non-multitasking environment. 


Linkage: 


RA: A(FCB) 
RB: A(Parameter list) 
Parameter list: 
A(DCLCB) 
ACRDV) /ACIOCB) /A(SDV) 
A(Event variable)/ (0) 
A (KEY | KEYFROM SDV) 7 (0) 
A(Request control block) 


Called by: IHEION, IHEOSW 


IHEITE 
Calls: 


Data management (BDAM), Supervisor 
(GETMAIN), IHESAP 


Entry point: IHEITFA 


Function: 


To provide the interface with BDAM for 
REGIONAL data sets opened for DIRECT 
access in a non-multitasking environment. 


Linkage: 


RA: A(FCB) 
RB: A(Parameter list) 
Parameter list: 
A (DCLCB) 
A(RDV) /A(IOCB) /A(SDV) 
A(Event variable)/(0) 
A (KEY | KEYFROM SDV) 7 (0) 
A(Request control block) 


Called by: IHEION 


IHEITG 
Calls: Data management (QSAM) 


Entry point: IHEITGA 


Function: 


To provide the interface with QSAM for 
CONSECUTIVE data sets opened for RECORD 
I/O with the BUFFERED attribute. 


Linkages 


RA: A(FCB) 
RB: A(Parameter list) 
Parameter list: 

A(DCLCB) 

A(RDV) /A (SDV) 

A(Error return)/ (0) 

A(0) 

A(Request control block) 


Called bys IHEION, IHEINT 
IHEITH 
Calls: 


Data management (BISAM), Supervisor 
(CHAP, DEQ, ENQ, GETMAIN), IHETSA 


Entry point: IHEITHA 

Function: 
To provide the interface with BISAM for 
accessing fixed length record INDEXED 
data sets opened for DIRECT access ina 
multitasking environment. 

Linkages: 


RA: A(FCB) 
RB: A(Parameter list) 


Parameter list: 
A(DCLCB) 
A(RDV) /A(IOCB) /A(SDV) 
A(Event variable) /(0) 
A(KEY | KEYFROM SDV)/(0) 
A(Request control block) 


Called by: IHEINT, IHETSW 


IHEITI 


Calls: 


Data management (BDAM), Supervisor (CHAP, 
DEQ, ENQ, GETMAIN), IHETSA 


Entry point: IHEITJA 
Function: 


To provide the interface with BDAM for 
REGIONAL data sets opened for DIRECT 
access in a multitasking environment. 


Linkage: 


RA: A(FCB) 
RB: A( Parameter list) 
Parameter list: 
A(DCLCB) 
A(RDV) /ACIOCB) /A(SDV) 
A(Event variable) / (0) 
A(KEY | KEYFROM SDV) /(0) 
A(Request control block) 


Called by: IHEINT 
LTHEITK 
Calls: 


Data Management (QSAM), Supervisor 
(GETMAIN, FREEMAIN) 


Entry point: IHEITKA 
Function: 


To provide the interface with QSAM for 
consecutive data sets opened for RECORD 
I/O Input with the BUFFERED attribute and 
VS or VBS format records. 


Linkage: 


RA: A(FCB) 
RB: A( Parameter list) 
Parameter list: 

A(DCLCB) 

A(RDV) /A(SDV) 

A(Error Return) /(0) 

A(0) | 

A(Request Control Block) 


Called by: IHEION, IHEINT 
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IHEITL 

Calls: 
Data Management (QSAM), Supervisor 
(GETMAIN, FREEMAIN) 


Entry point: IHEITLA 


Function: 
To provide the interface with QSAM for 
consecutive data sets opened for RECORD 


I/O Output with the BUFFERED attribute 
and VS or VBS format records. 


Linkage: as for IHEITK 


Called by: IHEION, IHEINT, IHEOCL 
IHEITM 
Calls: 


Data management (BISAM), Supervisor 
(GETMAIN), IHESAP 


Entry point: IHEITMA 
Function: 


To provide the interface with BISAM for 
accessing variable length record INDEXED 
data sets opened for DIRECT access ina 
non-multitasking environment. 


Linkage: 


RA: A(FCB) 
RB: A(Parameter list) 
Parameter list: 
A(DCLCB) 
A(CRDV) /A(IOCB) /A(SDV) 
A(EVENT variable)/ (0) 
A(KEY|KEYFROM SDV)/ (0) 
A(Request control block) 


Called by: IHEION, IHEOSW 
IHEITN 
Calis: 


Data management (QISAM), Supervisor 
(GETMAIN), IHESAP, IHETSA 


Entry point: IHEITNA 

Function: 
To provide the interface with QISAM for 
creating or accessing variable length 


record INDEXED data sets when opened for 
SEQUENTIAL access. 
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Linkage: 


RAs A(FCB) 
RB: A(Parameter list) 
Parameter list: 
A(DCLCB) 
A(RDV) /A(SDV) 
A(Error return)/(0) 
A(KEY| KEYFROM|KEYTO SDV)/(0) 
A(Request control block) 


Called by: IHEION, IHEINT 


IHELTO 
Callss 


Data management (BISAM), 
SUPERVISOR (CHAP, DEQ, ENQ, GETMAIN), IHETSA 


Entry point: IHEITOA 


Functions 


To provide the interface with BISAM for 

accessing variable length record INDEXED 
data sets opened for DIRECT access ina 

multitasking environment. 


Linkage: 


RAs: A(CFCB) 
RB: A( Parameter list) 
Parameter lists 
A(DCLCB) 
A(RDV) /ACIDCB) /A(SDV) 
AC(CEVENT variable)/ (0) 
A(KEY|KEYFROM SDV) /(0) 
A(Request control block) 


Called by: IHEINT, IHETSW 
IHEITP 
Calls: Data management (QTAM) 


Entry point: IHEITPA 


' Punctions 


To provide the interface with QTAM for 
teleprocessing files opened for record 
1/0. 


Linkages 


RA: A(CFCB) 
RB: A(Parameter list) 
Parameter lists: 
A(DCLCB) 
A(RDV) /A (SDV) 
A(Error return) /(0) 
A(KEY SDV) 
A(Request control block) 


Called by: IHEION, IHEINT 


IHEJXI 


Calls: IHESAP, IHETSA 


Ent int IHEJXII 


Function: 


To initialize IHEJXI to give bit 
addresses, and to find the first 
element of the array. 


Linkage: 
RA: A(ADV) 
RB: A(Number of dimensions) 
On returns 
RA: Bit address of first element 


Called by: IHENL2, IHESTG 


Entry point IHBJXIY 


Functions: 


As for IHEJXII but for byte addresses. 


Linkage: 


RA: A(ADV) 

RB: A(Number of dimensions) 
On return; 

RA: A(First element) 


Called by: 
IHEOSW, IHEPDF, IHEPDL, 


IHEPDX, IHEPDZ, IHESMF, 
IHESMX, IHESTG, IHETSW 


IHEPDS, IHEPDW, 
IHESMG, IHESMH, 


Entry point IHEJXIA 


Function: 
To find the next element of the array. 
Linkage: 


No explicit arguments 
Implicit arguments: 
LCA 
VDA, obtained in initialization 
On return: 
RA: Bit or byte address of the next 
element 
BR=0: Normal return 
BR=4: If the address of the last 
element of the array was provided 
on the previous normal return 


Called by: 


All modules calling IHEJXII and IHEJXIY 


IHEJXS 


Entry .point IHEJXSI 


Function: 


To find the first and last elements of 
an array and to give their addresses as 
bit addresses. 


Linkage: 
RA: A(CADV) 
RB: A(Number of dimensions) 
On Return: 
RO: Bit address of first element 
RA: Bit address of last element 


Called bys IHENL1 
Entry point IHEJXSY 
Functions: 
As for IHEJXSI but for byte addresses. 
Linkage: 
RA: A(ADV) 
RB: A(Number of dimensions) 
On return: 
RO: A(First element) 
RA: A(Last element) 
Called by: 
IHEPSF, IHEPSL, IHEPSS, IHEPSW, IHEPSX, 
IHEPSZ, IHESSF, IHESSG, IHESSH, IHESSX, 
IHENL1, compiled code for 
initialization purposes 
IHEKCA 
Entry point: IHEKCAA 
Function: 
To check that external data with a 
decimal picture specification is valid 
for that specification. 
Linkage: 


RA: A(Source) 
RB: A(Source DED) 


Called by: IHEDIE, IHEDIM 
IHEKCB 
Entry point: IHEKCBA 
Function: 

To check that external data with a 


sterling picture specification is valid 
for that specification. | 
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Linkage: 


RA: A(Source) 
RB: A(Source DED) 


Called by: IHEDIE 


IHEKCD 


Entry point IHEKCDA 


Function: 


To check that external data with a 
character picture specification is 
valid for that specification. The 
ONSOURCE address is stored. 


Linkage: 


RA: A(Source) 
RB: A(Source DED) 


Called by: IHEDIB 


Entry point IHEKCDB 


Function: 


As for IHEKCDA, but the ONSOURCE 
address is not stored. 


Linkage: As for IHEKCDA 
Called by: IHELDI 
IHELDI 
Calls: 


IHEDCN, IHEDMA, IHEDNB, IHEDNC, IHEIOF, 
IHEKCD, IHEPRT, IHEPTT, IHESAP, IHETSA, 
IHEUPA, IHEUPB, IHEVCA, IHEVCS, IHEVSC, 
IHEVSD 


Entry point IHELDIA 


Functions 


To read data from an input stream and 
to assign it to internal variables 
according to list-directed input 
conventions. 


Linkage: 


RA: A(Parameter list) 

Parameter lists: 
A(Variable, ) 
A(DED, ) 


A(Variabley) 


A(DEDy) 
(High-order byte of last argument 
indicates end of parameter list.) 
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Called by: Compiled code 


Entry point IHELDIB 


Function: 


As for IHELDIA but for single 
variables. 


Linkage: 


RAs A(Variable) 
RB: A(DED) 


Called by: Compiled code 


Entry point IHELDIC 


Function: 


To scan the value field (entry for 
data-directed input). 


Linkage: 


RA: A( Buffer SDV) 
RB: A(Control block) 
Control blocks H‘'VDA count so far‘ 
X*Flag box‘ (one byte) 
Return codes: 
BR=0: Not last item 
BR=4; Last item 
BR=8: End of file encountered before 
complete data field collected 


Called by: IHEDDI 
Entry .point IHELDID 
Function: 


To assign a value to a variable (entry 
for data-directed input). 


Linkage: 
RA: A(Variable) 
RB: A(DED) 
RC: A(Control block) 
Control block: H'VDA count so far‘ 
X'Flag box" (one byte) 
Called by: IHEDDI 
IHELDO 
Calls: IHEDNC, IHEIOF, IHEVSB, IHEVSC 
Entr Oint IHELDOA 
Function: 
To prepare data for output according to 


list-directed output conventions, and 
to place it in an output stream. 


Linkage: 


RA: A(Parameter list) 

Parameter list: 
A(Variable,) 
A(DED,) 


A(Variableny) 

A(DEDn) 

(High-order byte of last argument 
indicates end of parameter list.) 


Called by: Compiled code, IHEDDT 


Entry point IHELDOB 


Function: 


As for IHELDOA, but for only one item 
of the list of data. 


Linkage: 


RA: A(Variable) 
RB: A(DED) 


Called by: Compiled code, IHEDDT 


Entry point IHELDOC 
Function: 


As for IHELDOA, but used by 
data-directed output. 


Linkage: 
RA: A(Variable) 


RB: A(DED) 
RC: A(FCB) 


Called by: IHEDDO, IHEDDT 
IHELNL 
Entry point IHELNLE 
Function: 


LOG(x), where x is real long 
floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 

A(x) 

A(Target) 


Called ry: 


Compiled code, IHEHTL, IHELNZ, IHEXXL, 


ITHEXXZ 


Entry point IHELNL2 


Function: 


LOG2(x), where x is real long 
floating-point. 


Linkage: As for IHELNLE 
Called by: As for IHELNLE 


Entry point IHELNLD 


Function: 


LOG10(x), where x is real long 
floating-point. 


Linkage: As for IHELNLE 
Called by: As for IHELNLE 
IHELNS 
Entry point IHELNSE 


Function: 


LOG(x), where x is real short 
floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 

A(x) 

A( Target) 


Called by: 


Compiled code, IHEHTS, IHELNW, IHEXXS, 


THEXXW 
Entry point IHELNS2 
Function: 


LOG2(x), where x is real short 
floating-point. 


Linkage: As for IHELNSE 
Called by: As for IHELNSE 


Entry point IHELNSD 


Function: 


LOG10(x), where x is real short 
floating-point. 


Linkage: As for IHELNSE 
Called by: As for IHELNSE 


LHELNW 


Calls: IHEATS, IHELNS 
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Entry point: IHELNWO 
Function: 


-LOG(z), where z is complex short 
floating-point. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(z) 
A (Target) 
Called by: Compiled code, IHEXXW 
IHELNZ 
Calls: IHEATL, IHELNL 
Entry point: IHELNZO 


Function: 


LOG(z), where z is complex long 
floating-point. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(z) 
A (Target) 
Called by: Compiled code, IHEXXZ 
IHELSP 
Calls: Supervisor (FREEMAIN, GETMAIN) 


Function: 


Storage management for list processing. 


Entry point IHELSPA 


Function: 


To provide storage in an area variable 
for an allocation of a based variable. 


Linkage: 


RA: A(Eight-byte word-aligned parameter 
list) 

RB: A(ALLOCATE statement) 

Parameter list: 

Byte 0: Not used 

Bytes 1-3: A(Area variable) 

Byte 4: Offset of beginning of based 
variable from doubleword 
boundary 

Bytes 5-7: Length of based variable 


On return: 
RA: A(Eight-byte word-aligned parameter 
list) 
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Parameter list: 

Byte 0: Not used 

Bytes 1-3: A(Based variable) 

Byte 4: Offset of beginning of based 
variable from doubleword 
boundary 

Bytes 5-7: Length of based variable 

Called by: Compiled code 
Entry point IHELSPB 
Function: 


To free storage allocated to a based 
variable in an area variable. 


Linkage: 
RA: A(Eight-byte word-aligned parameter 
list) 
RB: A(€Area variable) 
Parameter list: 

Byte 0: Not used 

Bytes 1-3: A(Based variable) 

Byte 4: Offset of beginning of based 
variable from doubleword 
boundary 

Bytes 5-7: Length of based variable 

Called by: Compiled code 
Entry point IHELSPC 
Function: 
Assignments between area variables. 
Linkage: 


RA: A(Source area variable) 
RB: A( Target area variable) 


Called by: Compiled code. 
Entry point IHELSPD 
Function: 
To provide system storage for an 
allocation of a based variable (using 
GETMAIN macro).. 
Linkage: 


RA: A(Eight-byte word-aligned parameter 
list) 


Parameter list: 

Bytes 0-3: Not used 

Byte 4: Offset of beginning of based 
variable from doubleword 


boundary 


Bytes 5-7: Length of based variable 


On return: 


RAs A(Eight-byte word-aligned parameter 
list) 
Parameter list: 
Byte O: Not used 
Bytes 1-3: A(Based variable) 
Bytes 4-7: Not used 


Called by: Compiled code 


Entry point IHELSPE 


Functions: 


To free system storage allocated to a 
based variable (using FREEMAIN macro). 


Linkage: 


RA: A(Eight-byte word-aligned parameter 
list) 


Parameter list: 

Byte 0: Not used 

Bytes 1 - 3: A(Based variable) 

Byte 4: Offset of beginning of based 
variable from doubleword 
boundary 

Bytes 5 - 7: Length of based variable 


Called by: Compiled code 


IHELTT 


Calls: IHESAP, IHETSA, compiled code, 
operating system 


Functions: 


This module is the transfer vector 
table which is link-edited to the PL/I 
program when the Shared Library feature 
is selected. It formats the standard 
section of the PRV and is responsible 
for ensuring the correct entry to the 
PL/I program from the operating system. 
It also sets the address of the 
transfer vector tables into the first 
pseudo-register of the PRV. 


Entry point IHELTTA 
Functions 
Main entry point from operating system. 
Loads library module IHELTVA if this is 
not already resident and determines 
address Of IHELTVA. | 
Calis: IHESAP/IHETSA 


Called by: operating system 


Entr oint IHELTTB 


Function: 
Stores the addresses of the pseudo 
entry points of the transfer vector 


modules IHELTTA and IHELTVA in the PRV. 
(see * below) 


Called by: IHESAP/IHETSA 


Entry point IHELTTC 


Function: 
Deletes library module IHELTVA if this 
was loaded and returns to the operating 
system. 
Called bys 


compiled code (on completion of PL/I 
program) 


*Pseudo Entry points: IHELTT1, IHELTT2, 
IHELTT3, IHELTT4, IHELTTS 


Function: 
These act as reference points for the 
transfer vector tables when control is 
passed between the resident library 
modules and the partition. 

IHELTV 

Function: 
Transfer vector table link-edited to 
the resident library modules when 
shared library feature is selected. 
Formats standard section of PRV and 
locates transfer vector table pseudo 
entry points. 

Called bys IHELTT 

Entry point IHELTVA 

Function: 
Contains addresses of pseudo entry 
points (*see below) in first twenty 
bytes. 

Calied by: IHELTT 


*Pseudo Entry Points: IHELTV1, IHELTV2, 
IHELTV3, IHELTV4, IHELTVS 


Functions: as for IHELTT. 


THEM91 


Calls: IHEERR 
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Entry point IHEM91A 
Function: 
1. To analyze the exception or 
exceptions in an imprecise interrupt 
on Models 91 and 195 


2. To set up a list of these exceptions 
(in LWE) 


3. To raise the first of a series of 
PL/I conditions corresponding to 
these exceptions 

Linkage: 


PSW at interrupt is in current 
LWE + 112 


Called by: 


IHEERR, when an imprecise interrupt is 
detected 


Entry point IHEM91B 
Function: 
To continue raising, in succession, the 


PL/I conditions corresponding to the 
exceptions. 


Linkages 
List of exceptions is in current 
LWE + 136 

Called by: IHEERR 

Entry point IHEM91C 

Function: 
To print an error message for each 
unprocessed exception when, as a result 
of the processing of an earlier 
exception in the list, a program is 
forced to terminate before processing 
of the list is complete. 

Linkage: None 


Called by: IHEERR 


IHEMAI 
Entry point: IHEMAIN 
Functions 


Contains address of IHEBEGN; loaded only 
if there is no main procedure. 


Linkage: None 
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Called by: IHESAP, IHETSA 


IHEMPU 


Entry point: IHEMPUO 


Function: 


MULTIPLY (w,Z,Pp,q), where w and z are 
complex fixed binary, and (p,q) is the 
target precision. 


Linkage: 


RAs A(Parameter list) 
Parameter list: 

A(w) 

A(DED for w) 

A(z) 

A(DED for z) 

A(Target) 

A(DED for target) 


Called by: Compiled code 


IHEMPV 
Calls: IHEAPD 
Entry point: IHEMPVO 
Function: 
MULTIPLY (w,z,p,q), where w and z are 
complex fixed decimal, and (p,q) is the 
target precision. 
Linkage: 
RAs A(Parameter list) 
Parameter list: 
A(w) 
A(DED for w) 
A(z) 
A(DED for z) 
A(Target) 
A(DED for target) 
Called by: Compiled code 
IHEMSI 
Entry point: IHEMSIA 
Function: 
To call IHEERRC so that an error message 
is printed saying that STIMER facilities 
are unavailable. 
Called by: compiled code 
IHEMST 


Entry Points: IHEMSTA 


Function: 


To call IHEERRC so that an error message 
is printed saying that the TIME facility 
is unavailable. 


Called by: Compiled code 


IHEMSW 


Calls: 


Supervisor (FREEMAIN, WAIT), I/O transmit 
module whose address is in the FCB. 


Entry point: IHEMSWA 


Jf 


Function: 


1. According to the count passed, to 
return to the caller or to wait until 
a Single I/O event is complete. If 
the count is <0, immediate return is 
made; otherwise the event is waited 
on. 

2. To branch to the I/O transmit module 
to raise I/O conditions if necessary. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(Count) 
A(Event variable) 


Called by: Compiled code 


IHEMXB 


Entry point IHEMXBX 


Function: 


MAX(X4,X%a¢ee*eeX%n), where X4,X2 and Xn 
are real fixed-point binary. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 

A(x, ) 

A(DED for x,) 


A(xyn) 

A(DED for Xn) 

A(Target) 

A(Target DED) 

(High-order byte of last argument 
indicates end of parameter list.) 


Called by: Compiled code 


Entry point IHEMXBN 
Function: 
MIN (X4,Xa,e2ee,Xn), where x4,X2 and Xn 
are real fixed-point binary. 
Linkage: As for IHEMXBX 


Called by: Compiled code 


IHEMXD 
Entry point IHEMXDX 
Function: 
MAX (X4,%2,-2+,X%n), where x4,X2 and Xp 
are real fixed-point decimal. 
Linkage: 
RA: A( Parameter list) 
Parameter list: 


A(x,) 
A(DED for x,) 


A (xn) 

A(DED for Xn) 

A( Target) 

A(Target. DED) 

(High-order byte of last argument 
indicates end of parameter list.) 


Called by: Compiled code 
Entry point IHEMXDN 
Function: 
MIN(x4,,X%2---eeXn), where x4,X2 and Xp 


are real fixed-point decimal. 


Linkage: As for IHEMXDX 


Called by: Compiled code 
THEMXL 
Entry point IHEMXLX 
Function: 


MAX (xq ¢Xae--+,X%n), where x,,X2 and Xn 
are real long floating-point. 
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Linkage: 
RA: A(Parameter list) 
Parameter list: 


A(x,) 
A(x) 


Al(xn) 

A(Target) 

(High-order byte of last argument 
indicates end of parameter list.) 


Called by: Compiled code 


Entry point IHEMXLN 


Function: 


MIN (x4,X2,eee0e,Xn), Where X4,Xo and xy 
are real long floating-point. 


Linkage: As for IHEMXLX 


Called by: Compiled code 


ITHEMXS 


Entry point ITHEMXSX 


Function: 


MAX (x4 ee oeXn)e where Xe Xo and xn 
are real short floating-point. 


Calls: IHEJXS 
Linkage: 
RA: A(Parameter list) 
Parameter list: 


A(xX4) 
A(x2) 


A(xn) 
A( Target) 
(High-order byte of last argument 
indicates end of parameter list.) 
Called by: Compiled code 
Entry point IHEMXSN 


Function: 


MIN(Xq,.Xqeeee,Xn), where X4,X2 and xy 
are real short floating-point. 


Linkage: As for IHEMXSX 


Called by: Compiled code 
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IHEMZU 


Entry point IHEMZUM 


Function: 


Za*Zo, Where z, and Zag are complex 
fixed-point binary. | 


Linkage: 
RA: A(z) 
*RB: A(DED for Z,a) 
RC: A(za) 
*RD: A(DED for za) 


RE: A(Target) 
*RF: A( Target DED 


Called by: Compiled code, IHEXIU 


Entry point IHEMZUD 


Function: 


Z4/Za,e where Z, and Zz are complex 
fixed-point binary. 


Linkage: 

RA: A(z.) 

RB: AC(DED for Zq) 

RC; A( Za) 

*RD: AC(DED for za) 

RE: A(Target) 

*RF: A(Target DED) 
Called by: Compiled code 


IHEMZV 


Entry point IHEMZVM 


Function: 


Za*Zo, where Z4 and Zz are complex 
fixed-point decimal. 


Linkage: 
RA: A(z) 
RB: A(DED for Z.¢) 
RC: A(zoa) 
RD: A(DED for 23) 
RE: A(Target) 
*RF: A(Target DED) 
Called by: Compiled code, IHEXIV 
Entry point IHEMZVD 


Function: 


Za/Zae where z, and zz are complex 
fixed-point decimal. 


Linkage: As for IHEMZVM 


Called by: Compiled code 


IHEMZW 
Entry point: IHEMZWO 
Function: 


Z1*Za, where z, and Zz are complex short 
floating-point. 


Linkage: 
RAs A(z,4) 
RB: A(za) 
RC: A(Target) 
Called by: Compiled code, IHEXIW 
IHEMZZ 
Entry point: IHEMZZ0 


Function: 


Z1*Za, where Zz, and Z2 are complex long 
floating-point. 


Linkages: 


RA: A(z) 
RBs A(zo) 
RCs: A(Target) 


Called by: Compiled code, IHEXIZ 


IHENL1 


Calls: IHEJXS 


Entry point IHENLIA 


Functions 


ALL or ANY for a simple array (or an 
interleaved array of VARYING elements) 
of byte-aligned elements and a 
byte-aligned target. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(SADV) 
A(Number of dimensions) 
A(DED of the array) 
(ACIHEBSAO) for ALL, or 
(ACIHEBSOO) for ANY 
A(SDV for Target field ) 


Called by: Compiled code 
Entry point IHENLIL 
Function: 
ALL for a simple array (or an 
interleaved array Of VARYING elements) 


of elements with any alignment, and a 
target with any alignment. 


Linkage: 


RAs A(Parameter list) 
Parameter list: 
A (SADV) 
A(Number of dimensions) 
A(DED of the array) 
A (IHEBSFO) 
A(SDV for target field ) 


Called by: Compiled code 


Entry point IHENL1N 
Function: As for IHENLIL, but ANY. 


Linkage: As for IHENLIL 


Called by: Compiled code 


THENL2 


Calls: IHEJXI 


Entry point IHENL2A 
Function: 


ALL or ANY for an interleaved array of 
fixed-length byte-aligned elements and 
a byte-aligned target. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(SADV) | 
A(Number of dimensions) 
*A(DED of the array) 
(ACIHEBSAO) for ALL, or 
(A(IHEBSOO) for ANY 
A(SDV for target field) 


Called by: Compiled code 


Entry point IHENL2L 


Functions: 


ALL for an interleaved array of 
fixed-length elements with any 
alignment, and a target with any 
alignment. 


Linkage: 


RA: A(Parameter list) 
Parameter lists: 
A(SADV) 
A(Number of dimensions) 
*A(DED of the array) 
A (IHEBSFO) 
A(SDV for target field) 


Called by: Compiled code 
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Entry point IHENL2N 


Function: 
ANY for an interleaved array of 
fixed-length elements with any 
alignment, and a target with any 
alignment. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(SADV) 
A(Number of dimensions) 
*A(DED of the array) 
A(IHEBSFO) 
A(SDV for target field) 
Called by: Compiled code 
IHEOCL 
Calis: 


Supervisor (DCBD, FREEMAIN, LINK), IHECLI, 
ITHEIOF, IHEITC, IHEITL, IHEOPN, IHESAP 


Entry point IHEOCLA 
Function: 
Explicit open: links to IHEOPNA; 
handles error conditions detected by 
IHEOPN, IHEOPO, IHEOPP, IHEOPQ or 
IHEOPZ. 
Linkage: 


RA: A(OPEN parameter list) 
Parameter list: See IHEOPN 


Called by: Compiled code, IHEPRT 
Entry point IHEOCLB 
Functions: 
Explicit close: links to IHECLTA. 
Linkage: 


RA: A(CLOSE parameter list) 
Parameter list: See IHECLTA 


Called by: Compiled code 
Entry point IHEOCLC 
Function: 
To perform implicit open. 
Linkage: 
RA: A(OCB) 
RBs A(DCLCB) 
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Called by: IHEIOB, IHEION, IHESAP 
Entry point IHEOCLD 
Function: 
Implicit close: 
1. When a task is terminated, to close 
all the files opened in the task 
(by linking to IHECLTB). 
Linkage: 
RA: A(PRV of current task) 
Called by: IHESAP 
IHEOCT 
Calls: 
Supervisor (DCBD, DEQ, FREEMAIN, LINK), 


IHECTT, IHEIOF, IHEITC, IHEITL, IHEOPN, 
IHETSA 


Entry point IHEOCTA 
Function: 
Explicit open ina multitasking 
environment: links to IHEOPNA; handles 
error conditions detected by IHEOPN, 
IHEOPO, IHEOPP, IHEOPQ or IHEOPZ. 
Linkage: 


RA: A(OPEN parameter list) 
Parameter list: See IHEOPN 


Called by: Compiled code, IHEPTT 
Entry point IHEOCTB 
Function: 


Explicit close in a multitasking 
environment: links to IHECTTA. 


Linkage: 


RA: A(CLOSE parameter list) 
Parameter list: See IHECTTA 


Called by: Compiled code 
Entry point IHEOCTC 
Function: 


To perform implicit open in a 
multitasking environment. 


Linkage: 


RA: A(OCB) 
RB: A(DCLCB) 


Called by IHEIBT, IHEINT, IHETSA 


Entry point IHEOCTD 


Functions: 


Implicit close: 


1. When a task is terminated, to close 
all the files opened in the task 
(by linking to IHECTTB). 


2. To dequeue all records locked by 
the task and free the corresponding 
EXCLUSIVE blocks. 


To set all imcomplete EVENT 
variables complete, inactive, and 
abnormal, and to free the 
associated IOCBs. 


Linkage: 


RA: A(PRV of current task) 


Called by: IHETSA 


IHEOPN 
Calls: 


IHEOPO (via XCTL), IHEOPZ (via LINK), 
IHESAP, IHETSA 


Entry point: IHEOPNA 


Function: 


Open files: 
1. Merge declared attributes with OPEN 
options. 
2- Invoke IHEOPO. 
3. Invoke IHEOPZ if declared DIRECT 
OUTPUT (REGIONAL (1), (2) and (3) 
only). 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(OPEN Parameter list) 
A(Private Adcons) 


OPEN Parameter list: 

A(DCLCB, ) 

A(OPEN Control block,)7/0 
A(TITLE-SDV,)/0 
(Reserved) 

(Reserved) 

(Reser ved) 
A(LINESIZE, )/0 
A(PAGESIZE,)/0 


A(DCLCBn) 

A(OPEN Control blocky) /0 

A(TITLE-SDVyn) 7/0 

(Reser ved) 

(Reserved) 

(Reser ved) 

A(LINESIZEy) /0 

A(PAGESIZEn) /0 

(High-order byte of last argument 
indicates end of parameter list.) 


Called by: IHEOCL, IHEOCT 


IHEOPO 
Calls: 


Supervisor (DCB,DCBD,DEVTYPE,GETMAIN), 
IHEOPP (via XCTL), IHESAP, IHETSA 


Entry Point: IHEOPOA 


Function: 
1. To create and format the FCB. 


2. To set file register to A(FCB). 


Linkage: 


RA: A(Parameter list) 
Parameter lists: 
ACIHEOPN Parameter list) 
A(Subparameter list) 
Subparameter lists 
XL4'4en' (where nis the number of files 
to be opened) 
X*Access/Organization Code, ' 
AL3 (DCLCB,) | 
XL4'Merged attribute,‘ 


X*Access/Organization Code,‘ 
AL3 (DCLCB, ) 
XL4'Merged attribute,’ 


NOTE: Access/Organization Code is described 
in the module listing. 


Called by: IHEOPN 
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IHEOPP 
Calls: 


Supervisor (DCBD,GETMAIN,GETPOOL,OPEN), 
IHEOPQ (via XCTL), IHESAP, IHETSA 


Entry point: IHEOPPA 
Function: 


1. To invoke data management (OPEN 
macro). 


2. To establish defaults at DCB exit. 
3. To acquire initial IOCBs for BSAM. 
Linkage: 


RAs A(Parameter list) 
Parameter list: 
A(IHEOPN Parameter list) 
A(Subparameter list) 
Subparameter lists: 
XL4'4*n' (where n is the number of files 
to be opened) 
X"Access/Organization Code,' 
AL3 (DCLCB,) 
XL4*Merged attribute,’ 


X*Access/Organization Code,‘ 
AL3 (DCLCBn) 
XL4*Merged attribute,‘ 


NOTE: Access/Organization Code is described 
in the module listing. 


Called by: IHEOPO 
IHEOPQ 
Calis: 


Supervisor (DCBD,FREEPOOL, GETMAIN, LOAD), 
IHESAP, IHETSA 


Entry point: IHEOPQA 
Function: 


1. To load record-oriented I/0 
interface modules. 


2- TO link FCBs through the IHEQFOP 
chain. 


3. To acquire the initial IOCBs for 
BDAM and BISAM linkage. 


4. To simulate PUT PAGE when opening a 
PRINT file. 


Linkage: 


RA: A(Parameter list) 


126 


Parameter list: 
A(IHEOPN parameter list) 
A(Subparameter list) 
A(Data management OPEN parameter 
list) 


Subparameter list: 
XL4'4*n' (where n is the number of 
files to be opened) 
X"Access/Organization Code,‘ 
AL3 (DCLCB, ) 
XL4&"*Merged attributes, ‘ 


X*Access/Organization Code,‘ 
AL3 (DCLCBn) 
XL4'Merged attributes,‘ 


Data management OPEN parameter list: 
XL4*4#n' (where n is the number of 
files to be opened) 
X(Flags for data management OPEN 
executor, ) 
AL3 (DCB, ) 


X(Flags for data management OPEN 
executorn) 
AL3 (DCBn) 


NOTE: Access/Organization Code is described 
in the module listing. 


Called by: IHEOPP 
IHEOPZ 
Callss 


Supervisor (CHECK,CLOSE,DCB, DCBD, 
MAIN, FREEPOOL, GETBUF , GETMAIN, OPEN) 


FREE- 


Entry points: IHEOPZA 
Function: 
To provide the format for the initial 
allocation of a volume assigned to a | 
REGIONAL data set when opened for DIRECT 
OUTPUT. 
Linkage: 
RA: A(Parameter list) 
Parameter lists: 
A(Merged attributes) 
A(Entry in IHEOPN Parameter list) 
A(DCLCB) 
Called by: IHEOPN 
LHEOSD 
Calls: TIME macro 


Entry point: IHEOSDA 


Function: To obtain current date. 
Linkages 


RA: A(Parameter list) 
Parameter list: A(Target SDV) 


Called by: Compiled code 
IHEOSE 


Calls: IHESAP, IHETSA (to terminate the 
task) 


Entry point: IHEOSEA 

Function: 
To terminate the current task abnormally, 
raising the FINISH condition if it is the 
major task. 

Called by: Compiled code 

IHEOSI 

Calls: STIMER macro 

Entry point: IHEOSIA 


Function: 


To use the STIMER macro with the WAIT 
option for the implementation of DELAY. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
Interval of delay, in milliseconds, in 
a fullword 
Called by: Compiled code 
IHEOSS 


Calls: IHESAP, IHETSA (to terminate the 
task) 


Entry point: IHEOSSA 
Function: 


To raise the FINISH condition and 
abnormally terminate the job step. 


Linkage: None 

Called by: Compiled code 
IHEOST 
Entry Point: IHEOSTA 
Function: 


To use the TIME macro to obtain the time 
of day. 


Linkage: 


RA: A( Parameter list) 
Parameter list: A(Target SDV) 


Called by: Compiled code 


IHEOSW 
Calls: 


Supervisor (FREEMAIN,WAIT), IHEJXI, 
IHESAP, I/O transmit nodule whose address 
is in the FCB 


Entry points IHEOSWA 
Functions: 


To determine whether a specified number 
of events has occurred. If not, to wait 
until the required number is complete, 
and, in the case of I/O events, to branch 
to the I/O transmit module (which raises 
I/O conditions if necessary). 


This module is used in a non-muititasking 
environment. 


Linkage: 


RA: A(Parameter List) 
Parameter list: 


Word 1: 


1. If all events are to be waited 
on: 
Byte 0 = X’FF' 
Bytes 1 ~- 3 not used 
2. If a specified number (N) of 
events is to be waited ons 
Byte 0 = x‘00' | 
Bytes 1 - 3 = A(N) 


Subsequent words (one for each element 
Or array event): 


1. Array events: 
Byte 0O = dimensionality 
Bytes 1 - 3 = A(ADV) 
2. Element event: 
Byte 0 = xXx'0O0O* 
Bytes 1 - 3 = A(Event variable) 


(High-order byte of last argument 
indicates end of parameter list.) 


Called by: Compiled code 
IHEPDF 
Calls: IHEDMA, IHEJXI 


Entry point: IHEPDFO 
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Function: 
PROD for an interleaved array of real 
fixed-point binary or decimal elements. 
Result is real short or long 
floating-point. 
Linkage: 
RAs A(Parameter list) 
Parameter list: 
A (ADV) 
A(Number of dimensions) 
A(DED of the array) 
A (Target) 3 
A(DED for target) 
Called by: Compiled code 
IHEPDL 
Calis: IHEJXI 
Entry points: IHEPDLO 
Function: 
PROD for an interleaved array of real 
long floating-point elements. Result is 
real long floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(ADV) 
A(Number of dimensions) 
A(Target) 
Called by: Compiled code 
IHEPDS 
Calis: IHEJXI 
Entry point: IHEPDSO 
Function: 
PROD for an interleaved array of real 
short floating-point elements. 
real short floating-point. 
Linkage: 
RAs A(Parameter list) 
Parameter list: 
A(CADV) 
A(Number of dimensions) 
A(Target) 
Called by: Compiled code 
IHEP ' W 
Calls: IHEJXI 


Entry points: IHEPDWO 
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Result is 


Function: 


PROD for an interleaved array of complex 
short floating-point elements. Result is 
complex short floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(CADV) 
A(Number of dimensions) 
A(Target) 


Called by: Compiled code 


IHEPDX 


Calls: IHEDMA, IHEJXI 


Entry point: IHEPDX0O 
Function: 


PROD for an interleaved array of complex 
fixed-point binary or decimal elements. 
Result is complex short or long 
floating-point. 


Linkage: 


RAs A(Parameter list) 
Parameter list: 
A(ADV) 
A(Number of dimensions) 
A(DED of the array ) 
A(Target) 
A(DED for target) 


Called by: Compiled code 


IHEPDZ 


Calls: IHEJXI 


Entry point: IHEPDZ0 
Function: 


PROD for an interleaved array of complex 
long floating-point elements. Result is 
complex long floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(ADV) 
A(Number of dimensions) 
A(Target) 


Called by: Compiled code 


IHEPRT 
Calls: 


Supervisor (WTO, EXTRACT), IHEIOF, 
IHEOCL, IHESAP 


Entry point IHEPRTA 
Function: 
To COPY a data field on the SYSPRINT 
file, opening it if necessary. 
Linkage: 
RA: A(Character string) 


RB: A(Halfword containing length of 
character string) 


Called by: IHEIOD, IHELDI 
Entry point IHEPRTB 
Function: 
To write an error message on the 
SYSPRINT file, opening it if necessary. 
Also, to prepare for system action for 
CHECK condition. 
Linkage: AS for IHEPRTA 
Called by: IHEDDO, IHEERR, IHEESM, IHEESS 
IHEPSF 
Calls: IHEDMA, IHEJXS 
Entry point: IHEPSFO 
Function: 
PROD for a simple array of real 
fixed-point binary or decimal elements. 
Result is real short or long 
floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A (ADV) 
A(Number of dimensions) 
A(DED of the array) 
A(Target) 
A(DED for target) 
Called by: Compiled code 
IHEPSL 
Calls: IHEJXS 


Entry point: IHEPSLO 


Functions: 


PROD for a simple array of real long 
floating-point elements. Result is real 
long floating-point. 


Linkage: 


RAs A(Parameter list) 
Parameter list: 
A(ADV) 
A(Number of dimensions) 
A(farget) 


Called by: Compiled code 


IHEPSS 


Calls: IHEJXS 
Entry point: IHEPSSO 
Function: 
PROD for a simple array of real short 
floating-point elements. Result is real 
short floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(ADV) 
A(Number of dimensions) 
A(Target) 


Called by: Compiled code 


IHEPSW 
Calls: IHEJXS 
Entry point: IHEPSWO 
Functions: 
PROD for a simple array of complex short 
floating-point elements. Result is 
complex short floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(ADV) 
A(Number of dimensions) 
A(Target ) 
Called by: Compiled code 
IHEPSX 
Calls: IHEDMA, IHEJXS 


Entry point: IHEPSX0O 
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Function: 


PROD for a simple array of complex 
fixed-point binary or decimal elements. 
Result is complex short or long 

. floating-point. 


Linkage: 

RA: A(Parameter list) 

Parameter list: 

A(ADV) 
A(Number of dimensions) 
A(DED of the array elements) 
A (Target) | 
A(DED for target) 

Called by: Compiled code 
LHEPSZ 
Calls: IHEJXS 
Entry point: IHEPSZ0 
Function: 

PROD for a simple array of complex long 

floating-point elements. Result is 

complex long floating-point. 
Linkage: 

RA: A(Parameter list) 

Parameter list: 

A(ADV) 
A(Number of dimensions) 
A(Target) 

Called by: Compiled code 
IHEPTT 

This module is used in a multitasking 
environment and is equivalent to module 
IHEPRT in a non-multitasking environment. 
Calls: 


Supervisor (DEQ, ENQ, EXTRACT, WTO), 
IHEIOF, IHEOCT, IHETSA 


Entry point IHEPTTA 

Functions 
To COPY a data field on the SYSPRINT 
file, opening it if necessary, ina 
multitasking environment. 

Linkage: 
RA: A(Character string) 
RB: A(Halfword containing length of 

character string) 


Called by: IHEIOD, IHELDI, IHETEX 
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Entry point IHEPTTB 

Function: 
To write, in a multitasking 
environment, an error message on the 
SYSPRINT file, opening it if necessary. 
Also, to prepare for system action for 
CHECK condition. 

Linkage: As for IHEPTTA 


Called by: IHEDDT, IHEERR, IHETSA 


IHERES 


Entry point: IHEREST 


Functions: 


to restart program at last checkpoint. 


Linkage: None 
Called by: compiled code 
Entry point: IHERESN 
Function: 
to cancel automatic restart. 
Linkage: none 


Called by: compiled code, IHESAP 


ILHESAP 
Callss 


Supervisor ( FREEMAIN, GETMAIN, SPIE), 
IHEBEG, IHEMAN, IHEDDO, IHEOCL, IHEPRT 


Functions: 


Storage management in a non-multitasking 
environment. 


Entry point IHESADA (Get DSA): 
Function: 
To provide a DSA for a procedure or 
begin block and to set DR to point to 
it. 
Linkages 


RO: Length of DSA 
DR: A(Current save area) 


Called by: Prologues 


Entry point IHESADB (Get VDA): 
Function: 


To get a VDA for compiled code; sets 
RA=A(VDA). 


Linkage: 
RO: Length of VDA (excluding control 
words) 
DR: A(Current Save area) 


Called by: Compiled code 


Entry point IHESADD (Get CONTROLLED 
variable): 


Function: 
To provide storage for an allocation of 
a controlled variable, and to place the 
address of its fourth word in its 
pseudo-register. 
Linkage: 
RO: Lenoth of area (not including 
control words) 
RA: A(Controlled-variable pseudo- 
register) 
Called by: Compiled code 
Entry point IHESADE (Get LWS): 
Function: 


To provide a new LWS, and to update the 
LWS pseudo-registers. 


Linkage: None 
Called by: Library modules 

Entry point IHESADF (Get Library VDA): 
Function: 


To provide a VDA for library modules 
and to set RA = A(VDA). 


Linkage: 


RO: Length of VDA (including control 
words) 


Called by: Library modules 


Entry point IHESAFA (END): 


Function: 


Frees the DSA current at entry together 
with its associated VDAs. Request to 
free the DSA of the main procedure 
results in raising FINISH, closing all 
opened files, releasing automatic 


storage to the supervisor and finally 
returning to the supervisor with a 
return code of zero. 


Linkage: None 
Called by: Epilogues 

Entry point IHESAFB (RETURN): 
Function: 


Frees all chain elements up to and 
including the last procedure DSA in the 
chain. Can terminate a main procedure 
aS in IHESAFA. 


Linkage: None 
Called by: Compiled code 


Entry point IHES #FC (GO TO): 


Function: 


The DSA indicated by the invocation 
‘count, or pointed to by DR, is made 
current. All chain elements up to this 
DSA, with the exception of its VDAs and 
itself, are freed. 


Linkage: 


RA: A(Eight-byte word-aligned parameter 
list) 
Parameter list: 
Word 1 = Either Invocation count (bit 
0 of word 2 = Q) 
Or PR offset (bit 0 of word 
2 = 1) 
Word 2 = A(Location to which control 
is to be returned) 


Called by: Compiled code 
Entry point IHESAFD_ (Free VDA/LWS) 
Function: 


Frees the VDA or LWS at the end of the 
DSA chain. 


Linkage: 
IHEQSLA: A(VDA or LWS to be freed) 
(A VDA or LWS can be freed only when it 
is the last allocation) 


Called by: Compiled code, library modules 


Entry point IHES FF (Free controlled 
variable): 


Function: 
Frees the latest allocation of a 


controlled variable, and updates the 
associated pseudo-register. 
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Linkage: 


RA: A(Controlled variable pseudo- 
register) 


Called by: Compiled code 


Entry point IHESAFO 


Function: 
To close all files and to return to the 
supervisor. 


Linkage: None 


Called by: 


Library modules, IHEDUMP, IHEOSE, 
IHEOSS 


Entry point IHESAPA 


Function: 

1. To provide a PRV and LWS for a main 
procedure, and to issue a SPIE 
macro; then to transfer control to 
an address constant named IHEMAIN. 


2. TO pass a PARM parameter from the 
EXEC card. 


Linkage: 


L(PRV) from linkage editor 
L(LWS) from assembly of IHELIB 


Called by: Initial entry 
Entry Point ITHESAPB 
Function: 


As for IHESAPA, except that the code 
handling PARM parameter is bypassed. 


Linkage: 


L(PRV) from linkage editor 
L(LWS) from assembly of IHELIB 


Entry point IHESAPC 

Function: 
As for IHESAPA, but also reserves a 
512-byte area for optimization 
purposes. 

Linkage: 
L(PRV) from linkage editor 
L(LWS) from assembly of IHELIB 
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Entry point IHESAPD 
Function: 
As for IHESAPB, but also reserves a 
512-byte area for optimization 
purposes. 
Linkage: 


L(PRV) 
L(LWS) 


from linkage editor 
from assembly or IHELIB 


Entry point IHESARA 
Function: 


To restore the environment of a program 
to what it was before: 


1. the execution of an ON statement 
associated with the on-unit to be 
entered, or 


2. the passing of the entry parameter 
associated with the called 
procedure. 


Then to branch to the on-unit or the 
procedure. 


Linkage: 


RA: A( Parameter list) 
Parameter list: 
A(Entry parameter). The entry 
parameter is an 8-byte field 
containing: 


1st word: On-unit or entry address 


Invocation count of the 
DSA associated with 
either the passing 
procedure or the 
procedure in which the ON 
Statement was executed 


2nd word: 


Called by: Compiled code, IHFERR 
Entry point IHESARC 
Function: 


To place the return code in the 
pseudo-register IHEQRTC. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(Return code) (The return code is 
fullword fixed binary.) 


Called by: Compiled code 


Entry point IHESATA 


Function: 
To provide the interface between 0/S 
STAE routine and the PL/I STAE routine. 
Linkage: 


RA = address of O/S STAE parameter 
list. 


Called by: SUPERVISOR 


Calls: 

IHESHL 

Calls: IHEEXL 

Entry point IHESHLS 
Function: 


SINH(x), where x is real long floating- 
point. 


Linkage: 
RA: A Parameter list) 
Parameter list: 
A(x) 
A(Target) 
Called ky: Compiled code 


Entry point IHESHLC 


Function: 


COSH(x), where x is real long 
floating-point. 


Linkage: As for IHESHLS 
Called by: Compiled code 

IHESHS 

Calls: IHEEXS 

Entry point IHESHSS 
Function: 


SINH(x), where x is real short 
floating-point. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A(Target) 


Called by: Compiled code 


Entry point IHESHSC 


Function: 
COSH(x), where x is real short 
floating-point. 

Linkage: As for IHESHSS 


Called by: Compiled code 


LHESIZ 


Entry point: IHESIZE 
Function: | 

to return the length of the PRV in RA. 
Linkage: none 


Called by: IHESAP, IHETSAP 


LHESMF 


Calls: IHEDMA, IHEJXI 
Entry point: IHESMFO 


Function: 


SUM for an interleaved array of real 
fixed-point binary or decimal elements. 
Result is real short or long 
floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(ADV) 
A(Number of dimensions) 
A(DED of the array) 
A(Target) 
A(DED for target) 


Called by: Compiled code 


IHESMG 


Calls: IHEJXI 


Entry point IHESMGR 


Function: 
SUM for an interleaved array of real 


short floating-point elements. Result 
is real short floating-point. 
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Linkage: 
RA: A(Parameter list) 
Parameter list: 
A (ADV). | 
A(Number of dimensions) 
A(Target) 
Called by: Compiled code 
Entry point ITHESMGC 
Function: 
SUM for an interleaved array of complex 
short floating-point elements. Result 
is complex short floating-point. 
Linkage: As for IHESMGR 
Called by: Compiled code 
IHESMH 
Calls: IHEJXI 
Entry point IHESMHR 
Function: 
SUM for an interleaved array of real 
long floating-point elements. Result 
is real long floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(ADV) 
A(Number of dimensions) 
A (Target) 
Called by: Compiled code 
Entry point IHESMHC 
Function: 
SUM for an interleaved array of complex 
long floating-point elements. Result 
is complex long floating-point. 
Linkage: As for IHESMHR 
Called by: Compiled code 
IHESMX 
Calis: IHEDMA, IHEJXI 
Entry point: IHESMX0 
Function: 
SUM for an interleaved array of complex 
fixed-point binary or decimal elements. 


Result is complex short or long 
floating-point. 
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Linkage: 

RA: A(Parameter list) 

Parameter list: 
A(ADV) | 
A(Number of dimensions) 
A(DED of the array) 
A(Target) 
A(DED for target) 


Called by: Compiled code 


IHESNL 
Entry point IHESNLS 
Function: 
SIN(x), where x is real long 
floating-point. 
Linkage: 


RA: A( Parameter list) 
Parameter list: 


A (x) 
A(Target) 


Called by: Compiled code, IHEEXZ, IHESNZ 


Entry point IHESNLZ 
Function: 
SIND(x), where x is real long 
floating-point. 
Linkage: As for IHESNLS 


Called by: Compiled code 


Entry point IHESNLC 
Function: 


CoS(x), where x is real long 
floating-point. 


Linkage: As for IHESNLS 


Called by: Compiled code, IHEEXZ, IHESNZ 


Entry point IHESNLK 


Function: 


COSD(x), where x is real long 
floating-point. 


Linkage: As for IHESNLS 


Called by: Compiled code 


IHESNS 
Entry point IHESNSS 


Function: 





SIN(x), where x is real short 
floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 

A(x) 

A(Target) 


Called by: Compiled code, IHEEXW, IHESNW 


Entry point IHESNSZ 


Function: 
SIND(x), where x is real short 
floating-point. 

Linkage: As for IHESNSS 


Called by: Compiled code 


Entry point IHESNSC 
Function: 
CcoS(x), where x is real short 
floating-point. 
Linkage: As for IHESNSS 
Called Ly: Compiled code, IHEEXW, IHESNW 


Entry point IHESNSK 


Function: 


COSD(x), where x is real short 
floating-point. 

Linkage: As for IHESNSS 

Called ky: Compiled code 


IHESNW 
Calis: IHEEXS, IHESNS 


Entry point IHESNWS 


Function: 


SIN(z), where z is complex short 
floating-point. 


Linkage: 


RA: A( Parameter list) 
Parameter list: 

A(z) 

A(Target) 


Called by: Compiled code 


Entry point IHESNWZ 


Function: 


SINH(z), where z is complex short 
floating-point. 


Linkage: As for IHESNWS 


Called by: Compiled code 


Entry point IHESNWC 


Function: 


coS(z), where z is complex short 
floating-point. 


Linkage: As for IHESNWS 


Called by: Compiled code 


Entry point IHESNWK 


Function: 


COSH(z), where z is complex short 
floating-point. 


Linkage: As for IHESNWS 


Called by: Compiled code 


LHESNZ 
Calls: IHEEXL, IHESNL 


Entry point IHESNZS 


Function: 


SIN(z), where z is complex long 
floating-point. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(z) 
A( Target) 
Called by: Compiled code 
Entry point IHESNZZ 
Function: 
SINH(z), where z is complex long 
floating-point. 
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Linkage: As for IHESNZS 


Called by: Compiled code 


Entry point IHESNZC 


Function: 
CcoS(z), where z is complex long 
floating-point. 

Linkage: As for IHESNZS 


Called by: Compiled code 


Entry point ITHESNZK 
Function: 
COSH(z), where z is complex long 
floating-point. 
Linkage: As for IHESNZS 
Called by: Compiled code 
LTHESPR 
Entry point: IHESPRT 
Function: 
Contains the default DCLCB for SYSPRINT. 
This module is used only when no other 
DCLCB is provided. 
Called by: IHEPRT, IHEPTT 
ITHESOL 
Entry point: IHESQLO 
Function: 


SQRT(x), where x is real long 
floating-point. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A(Target) 
Called by: Compiled code, IHEABZ, IHESQZ 
IHESQS 
Entry point: IHESQSO 
Function: 
SORT(x), where x is real short 


floating-point. 
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Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A(Target) 


Called by: Compiled code, IHEARBW, IHESQW 


IHESOW 
Calls: IHESQS, IHEABW 


Entry point: IHESQWO 


Function: 
SQRT(z), where z is complex short 
floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(z) 
A(Target) 
Called by: Compiled code 
LHESOZ 
Calls: IHEABZ, IHESOL 
Entry point: IHESQZ0 


Function: 


SQORT(z), where z is complex long 
floating-point. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(z) 
A(Target) 
Called by: Compiled code 
IHESRC 
Entry point IHESRCA 
Function: 
Returns SDV of erroneous field 
(ONSOURCE pseudo-variable). If used 
out of context, the ERROR condition is 
raised. 


Linkage: 


RA: A( Parameter list) 
Parameter list: A(Dummy SDV) 


Entry int IHESRCB 


Function: 
Assigns erroneous character to target 
(ONCHAR built-in function). If used 


out of context, then ‘blank‘' is 
returned. 


Linkages 


RA: A(Parameter list) 
Parameter list: A(Target SDV) 


Entry point IHESRCC 


Function: 
Returns SDV of erroneous field 
(DATAFIELD). If used out of context, a 
null string is returned. 


Linkage: As for IHESRCA 


Entry point IHESRCD 


Function: 
Returns SDV of erroneous character. 
(ONCHAR pseudo-variable). If used out 
of context, the ERROR condition is 
raised. 
Linkage: As for IHESRCA 
Entry point IHESRCE 
Function: | 
Returns SDV of the name of the file 
(ONFILE) which caused entry to the 
current ON block. If used out of 
context a null string is returned. 
Linkage: As for IHESRCA 
Fntry point IHESRCF 
Function: 
Returns SDV of erroneous field 
(ONSOURCE built-in function). If used 
out of context, a null string is 
returned. 
Linkages As for IHESRCA 
IHESRD 
Entry point: IHESRDA 
Function: 
Returns SDV of current key (ONKEY 


built-in function). If used out of 
context, a null string is returned. 


Linkage: 


RA: A(Parameter list) 
Parameter list: A(Dummy SDV) 


THESRT 


Calls: 


IHESAP, IHETSA, Supervisor (GETMAIN, 
FREEMAIN, LINK, SPIE), SORT 


Function: 


To call dynamically, through the use of 
a LINK macro, the operating system 
Sort/Merge from Within a PL/I 
procedure, and, optionally, permitting 
the use of Sort/Merge user exits E15 
and E35 to invoke PL/I exit procedures 
contained within the calling PL/I 
procedure. 


Entry point IHESRTA 


Function: 


To call operating system Sort/Merge to 
sort a predefined file (SORTIN) placing 
the sorted records on another 
predefined file (SORTOUT). 


Linkage: 


RA: A(Parameter list) 
Parameter list: 


1. ACA character string which 
represents the Sort/Merge control 
card to describe the sort fields 
contained in the record.) 


2. ACA character string which 
represents the Sort/Merge control 
card to describe the record 
format of the records which are 
to be sorted.) 


3. ACA fullword fixed binary value 
specifying the amount of core 
storage available to Sort/Merge.) 


4%. A(A fullword fixed binary value 
to be used as a return code from 
the sort. A return code of 0 
indicates the successful 
completion of the sort, 16 
indicates an unsuccessful sort 
operation.) 


5. A(SDV for the DD name replacement 
String). This is an optional 
parameter. 


Called bys: Compiled code (PL/I source 


statement ) 
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Entry point [HESRTB 


Function: 


To call operating system Sort/Merge to 
sort individual records, passed to 
Sort/Merge through user exit E15 by a 
PL/I exit procedure, onto a predefined 
file (SORTOUT). 


Linkages 


RA: A(Parameter list) 
Parameter list: 
1, 2, 3, and 4 are as for IHESRTA 


5. A(The PL/I functional procedure 
entry name invoked by Sort/Merge 
user exit E15. This exit 
procedure returns a character 
string representing a record 
which is to be included in the 
sort.) 


6. as for 5 in IHESRTA 


Called by: Compiled code (PL/I source 


statement) 
Entry point IHESRTC 


Functions: 


To call operating system Sort/Merge to 
sort a predefined file (SORTIN), 
passing individual sorted records 
through Sort/Merge user exit E35 to a 
PL/I exit procedure. 


Linkage: 


RA: A(Parameter list) 
Parameter lists: 
1, 2, 3, and 4 are as for IHESRTA 


5. A(The PL/I procedure entry name 
invoked by Sort/Merge user exit 
E35. This exit procedure 
receives a sorted record from the 
sort.) 


6. as for 5 in IHESRTA 


Called by: Compiled code (PL/I source 


statement) 
Entry point IHESRTD 


Functions 


To call operating system Sort/Merge to 
sort individual records passed to the 
sort by an exit procedure, through user 
exit E15, and to pass the sorted 
records, through user exit E35, to an 
exit procedure. 
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Linkage: 


RA: A( Parameter list) 
Parameter list: 
1, 2, 3, and 4 as for IHESRTA 
5. as for IHESRTB 
6. as for 5 IHESRTC 
7. as for 5 in IHESRTA 


Called by: Compiled code (PL/I source 
statement ) 


IHESSF 





Calis: IHEDMA, IHEJXS 
Entry point: IHESSFO 
Function: 


SUM for a simple array of real 
fixed-point binary or decimal elements. 
Result is real short or long 
floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(ADV) 
A(Number of dimensions) 
A(DED of the array) 
A (Target) 
A(DED for target) 


Called by: Compiled code 
IHESSG 
Calls: IHEJXS 
Entry point IHESSGR 
Function: 
SUM for a simple array of real short 
floating-point elements. Result is 
real short floating-point. 
Linkage: 
RA: A( Parameter list) 
Parameter list: 
A (ADV) 
A(Number of dimensions) 
A(Target) 
Called bys Compiled code 
Entry point IHESSGC 
Function: 
SUM for a simple array of complex short 


floating-point elements. Result is 
complex short floating-point. 


Linkage: As for IHESSGR 


Called by: Compiled code 


IHESSH 


Calis: IHEJXS 


Entry point IHESSHR 
Function: 


SUM for a simple array of real long 
floating-point elements. Result is 
real long floating-point. 

Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(ADV) 
A(Number of dimensions) 
A(Target) 


Called by: Compiled code 


Entry point IHESSHC 


Function: 
SUM for a simple array of complex long 
floating-point elements. Result is 
complex long floating-point. 
Linkage: As for IHESSHR 
Called by: Compiled code 
IHESSX 
Calls: IHEDMA, IHEJXS 
Entry point: IHESSX0 
Function: 
SUM for a simple array of complex 
fixed-point binary or decimal elements. 


Result is complex short or long 
floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A (ADV) 
A(Number of dimensions) 
A(DED of the array ) 
A(Target) 
A(DED for target) 


Called by: Compiled code 
IHESTA 


Entry point: IHESTAA 


Function: 


Write out error messages under ABEND 
conditions. 


Linkage: 
RA: A(PLIST) 
PLIST: A(Latest save area) 
A(O/S STAE parameter list) 
A(First free core block) 
Unused 
A(Adcon list) 
A(SYSPRINT in PRV) 


Called bys IHESAP 


IHESTG 


Calls: IHEJXI, IHEBSK 


Entry point IHESTGA 





Function: 
Given a structure dope vector and its 
DVD, returns a fullword containing the 
string length which would result from 
the concatenation of all the elements 
of the structure. 
Linkage: 
RA: A(Structure dope vector) 
RB: A(DVD) 
RC: A(One-word target field) 
Called by: Compiled code 
Entr Oint IHESTGB 
Function: 
Given a structure dope vector and its 
DVD, assigns the result of 
concatenating all the elements of the 
structure to a string target. 
Linkage: 
RA: A(Structure dope vector) 
RB: A(DVD) 
RC: A(Target) 
Called by: Compiled code 
IHESTP 
Calls: IHEBSK, IHEBSM, IHEJXTI 
Entry point: IHESTPA 
Function: 
Assigns a bit or character string to 


the elements of a scalar, array or 
structure variable. 
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Linkage: 


RA: A(Dope Vector) 
RB: A(Dope Vector Descriptor) 
RC: A(SDV) 


Called by: Compiled code. 


ITHESTR 


Calls: IHESAP, IHETSA 


Entry point IHESTRA 


Function: 


To compute the address of the first 
element of a structure and the total 
length of the structure, using a 
complete structure dope vector. The 
result in the two-word target field is: 


ist word: A(Start of structure), in 
bytes and bit offset 


2nd word: Length of structure, in 
bytes 


Linkage: 


RAs A(Structure dope vector) 
RB: A(DVD) 
RC: A(Two-word target) 


Called by: Compiled code 


Entry point IHESTRB 


Function: 


Given a partially completed structure 
dope vector, to map a structure 
completely, namely: 


1. Locating each structure base 
element on the alignment boundary 
required by its data type. 


2. Calculating the offset of the start 
of each base element from the byte 
address of the beginning of the 
structure. 


3. Calculating the multipliers of all 
arrays appearing in the structure 
and calculating the offset of the 
virtual origin of each array from 
the byte address of the beginning 
of the structure. 


4. Calculating the total length of the 
structure. 


5. Calculating the offset from the 
maximum alignment boundary in the 
structure to the byte address of 
the start of the structure. 
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The result is a completed structure 
dope vector, and a target field which 
contains: 
0 7 8 31 
Ce eer a er ee po ee ee 


| Zero | 


t T 
| Offset | Length | 


Offset: Offset in bytes from the maximum 
alignment boundary in the structure 
to the start of the structure 

Length: Length of structure, in bytes 

Linkages: As for IHESTRA 
Called by: Compiled code 
Entr Oint IHESTRC 


Function: 


As for IHESTRB, but using the COBOL 
structure mapping algorithm. 


Linkage: As for IHESTRA 
Called by: Compiled code 

IHESUB 

Calis: IHETSAM 

Entry point: IHESUBA 
Function: 


to be attached by IHETSAP and pass 
control to IHETSAM. 


Linkage: 


RO(length of PRV) 
RA: A( Parameter list) 


Parameter list: 
A (IHETSAM) 
A(Parameter list) 
Called by (attached by): IHETSAP. 
LHETAB 
Base address of table: IHETABS 
Functions: 
This module is a table of default 
information provided for use at 
installation or when individual program 
replacements are required. It contains: 
1. Default PAGESIZE, LINESIZE, and left 


and right margin positions for all 
PRINT files. 


2. Default tabulation positions for 
list- and data-directed PRINT file 
output. 

LHETCV 
Calls: Supervisor (FREEMAIN, GETMAIN) 
Entry point IHETCVA 

Function: 

To provide storage for an allocation of 
a controlled variable in a multitasking 
environment, and to place the address 
of its fourth word in its 
pseudo-register. 

Linkage: 

RO: Length of area (excluding control 
words ) 

RA: A(Controlled-variable 
pseudo-register) 

Called by: Compiled code 

Entry point IHETCVB 

Function: 

Frees the latest allocation of a 
controlled variable in the current 
task, and updates the associated 
pseudo-register. 

Linkage: 

RA: A(Controlled-variable 
pseudo-register) 

Called by: Compiled code 

IHETEA 

Calls: Supervisor (POST, WAIT) 

Entry point: IHETEAA 

Function: Event variable assignment. 


Linkage: 


RA: A(Source event variable) 
RB: A(Target event variable) 


Called by: Compiled code 

IHETER 

Entry point: IHETERA 

Function: 
To search for a matching ON field in a 
multitasking environment by chaining 
through DSAs and PRV VDAs. A return code 


is set in register BR to indicate the 
result of the search. 


Linkage: DR: A(LWE) 


Called by: IHEERR 


IHETEV 


Calls: Supervisor (POST,WAIT) 


Entry point: IHETEVA 


Function: 


COMPLETION pseudo-variable (COMPLETION (v) 
= expression): sets the specified event 
variable complete or incomplete according 
to the evaluation of the expression. 


Linkage: 


RA: A(Parameter list) 

Parameter list: 
A(Event variable) 
A(Fullword to hold completion value (in 
bit 24)) 


Called by: Compiled code 
IHETEX 
Calls: 


ITHEERT, IHEPTT Supervisor (WTO, LOAD, 
DELETE, EXTRACT, ENQ, DEQ, PUT) 


Entry point IHETEXA 
Function: 


To generate a message when a task has 
been terminated while still active due 
to the freeing of the block in which 
the task was attached. 


Linkage: 


RA contains the address of a VDA which 
contains space for the creation of the 
message and the following parameters: 


A (IHEPTTB) 

A(Symbol table entry for which the 
task has been terminated) 

A (IHEQSPR) 


Called by: IHETSA 
Function: 
To generate a message when a task has 


been abnormally terminated by the 
operating system. 
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Linkage: 
DR points to an area of storage 
containg a save area, an area for the 


creation of the message and the 
following parameters: 


Completion code 

A(Symbol table entry for the task 
which has been terminated) 

A(IHEQSPR) 


Called by: IHETSA 


Entry point IHETEXC 


Function: 


Version 5 entry point (instead of 
IHETEXB) 


Linkage: 
A(PROC NAME) 
Statement no. when task abended 
Offset when task abended 
A(Symbol table) 
Completion code 
A(SYSPRINT in major PRV) 


Called by: IHETSA 


IHETHL 

Calls: IHEEXL 

Entry point: IHETHLO 
Function: 


TANH(x), where x is real long floating- 
point. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A(Target) 
Called by: Compiled code, IHETNZ 
LHETHS 
Calls: IHEEXS 
Entry point: IHETHSO 
Function: 
TANH(x), where x is real short 
floating-point. 
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Linkage: 


RA: A(Parameter list) 
Parameter list: 

A(x) 

A(Target) 


Called by: Compiled code, IHETNW 


IHETNL 


Entry point IHETNLR 


Function: 


TAN(x), where x is real long 
floating-point. 


Linkage: 
RA: A( Parameter list) 
Parameter list: 
A(x) | 
A( Target) 
Called by: Compiled code, IHETNZ 
Entry point IHETNLD 


Function: 


TAND(x), where x is real long 
floating-point. 


Linkage: As for IHETNLR 
Called by: Compiled code 
LHETNS 
Entry point IHETNSR 
Function: 


TAN(x), where x is real short 
floating-point. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(x) 
A( Target) 


Called by: Compiled code, IHETNW 
Entry point IHETNSD 
Function: 


TAND(x), where x is real short 
floating-point. 


Linkage: As for IHETNSR 


Called by: Compiled code 


IHETNW 


Calls: IHETHS, IHETNS 


Entry point IHETNWN 


Function: 


TAN(z), where z is complex short 
floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 

A(z) 

A(Target) 


Called by: Compiled code 


Entry point IHETNWH 
Function: 


TANH(z), where z is complex short 
floating-point. 


Linkage: As for IHETNWN 


Called by: Compiled code 


IHETNZ 

Calls: IHETHL, IHETNL 

Entry point IHETNZN 
Function: 


TAN(z), where z is complex long 
floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(z) 
A( Target) 


Called by: Compiled code 


Entry point IHETNZH 


Function: 


TANH(z), where z is complex long 
floating-point. 


Linkage: As for IHETNZN 


Called by: Compiled code 


IHETOM 
Calls: Supervisor (WTO, EXTRACT) 


Entry point IHETOMA 
Function: 


Issues WTO macro instruction if the 
program does not have a main procedure. 


Linkage: 


DR points to an area of storage which 
is used as a save area and aS workspace 


to build up the message. 
Called by: IHEBEG 
Entry point IHETOMB 
Function: 


Issues WTO macro instruction if the PRV 
is longer than 4096 bytes. 


Linkage: 
As for IHETOMA 
Called by: IHEBEG 


Entry point IHETOMC 
Function: 


Issues WTO macro instruction if there 
has been an interrupt in the error 
handler. 


Linkage: 
As for IHETOMA 


Called by: IHEERR 


Entry point IHETOMD 
Function: 


Issues WTO macro instruction if the 
major task of a multitasking program 
has been terminated with an ABEND. The 
message contains the completion code. 


Linkage: 


As for IHETOMA but in addition the 
completion code is passed in the area 
pointed to by DR. 


Called by: IHETSA 


Entry point IHETOME 
Function: 


Issues WTO macro instruction if there 
is an abnormal KEY condition when: 
CLOSING a file after a LOCATE 
statement. The file may be INDEXED 
(with RKP # 0) or REGIONAL. 
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Linkage: as for IHETOMA 


Called by: IHEOCL, IHEOCT 


IHETPB 


Entry point: IHETPBA 
Function: 


PRIORITY built-in function: returns the 
priority of a named task relative to the 
priority of the current task. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(Task variable) 
A(Fullword target field) 


Called by: Compiled code 


LHETPR 
Calls: Supervisor (CHAP, POST,WAIT) 


Entry point: IHETPRA 


Function: 


PRIORITY pseudo-variable (PRIORITY(v) = 
expression): sets the priority of the 
specified task to the given value 
relative to the priority of the current 
task. 


Linkage: 
RA: A(Parameter 1list) 
Parameter list: 
A(fTask variable), or zero (if current 
task) 
A(Relative priority) 


Called by: Compiled code 


IHETSA 

Calls: 
Supervisor (ATTACH, DEQ, DETACH, EXTRACT, 
FREEMAIN, GETMAIN, LINK, POST, SPIE, 
STAE, WAIT), IHEBEG IHEDDT, IHEERR, 
IHEMAI, IHEITA, IHEOCT, IHEPTT, IHESIZ, 
IHETAB, IHETEX 

Function: 
Object program management in a 
multitasking environment. 
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Entry point IHETSAA 
Function: 


1. Obtains storage for the PRV VDA, 
task variable, and event variable 
for the major task, ECBLIST, CTECB 
and TCA. 


2. Attaches the PL/I major task and 
then enters a wait state until 
either the event variable for the 
major task or the CTECB is 
completed. 


The execution of IHETSAA is termed the 
control task. Return is made to the 
calling program when there are no 
outstanding tasks in the calling 
program. | 

Linkage: 


L(PRV) from IHESIZE 
L(LWS) from assembly of IHELIB 


Called by: 


Program that calls the PL/I program. 


Entry point IHETSAC 
Function: 


To place the return code in the 
pseudo-register IHEQRTC. 


Linkage: 
RA: A(Parameter list) 
Parameter List: 
A(Return code) (The return code is 
fullword fixed binary.) 
Called by: Compiled code 
Entry point TIHETSAD (Get DSA) 
Function: 
To provide a DSA for a procedure or 
begin block and to set DR to point to 
it. 
Linkage: 


RO: Length of DSA 
DR: A(Current save area) 


Called by: Prologues, IHESRT 


Entry point IHETSAE (END) 
Function: 
Frees the DSA current at entry and its 


associated VDAs, and abnormally 
terminates any tasks attached in the 


block. A request to free the first DSA 
in a subtask results in the closing of 
all files opened, the dequeuing of 
resources enqueued, and the release of 
all dynamic storage allocated in that 
task. A request to free the DSA of the 
main procedure also raises the FINISH 
condition, but does not cause 
controlled storage allocated in the 
major task to be freed. 


Linkage: None 


Called by: Epilogues, IHESRT 


Entry point IHETSAF (Free VDA/LWS) 


Function: 


Frees the VDA or LWS at the end of the 
DSA chain. 


Linkage: 


IHEQSLA: A(VDA or LWS to be freed) 
Only the most recently allocated VDA or 
LWS can be freed. 


Called by: Compiled code, library modules 


Entry point IHETSAG (GO TO) 


Function: 


The DSA indicated by the invocation 
count, or pointed to by DR, is made 
current. All chain elements up to this 
DSA, with the exception of its VDAs and 
itself, are freed. Any active tasks 
attached to the DSAs freed are 
abnormally terminated. 


Linkage: 


RA: A(Eight-byte word-aligned parameter 
list) 


Parameter list: 


Invocation count (bit 
0 of word 2=0) 

or PR offset (bit 0 of word 
2=1) 


Word 1=either 


Word 2=A(Location to which control is 
to be returned) 


Called by: Compiled code 
Entry point IHETSAL (Get LWS) 
Function: 


To provide a new LWS, and to update the 
LWS pseudo-registers. 


Linkage: None 

Called by: Library modules 
Entry point IHETSAM 

Function: 


Initializes new subtasks, and, where 
applicable, the PRV and primary LWS for 
the major task. Issues a SPIE and STAE 
macro instructions and branches to the 
main procedure. 


Linkage: 


RA: A( Parameter list) 
Parameter list contains control 
information from the control task. 


Called by: IHESUBA 


Entry point IHETSAN 


Function: 


To change the environment of a program 
to that which existed at the time of 


1. the execution of an ON statement 
associated with the on-unit to be 
entered, or 


2. the passing of the entry varameter 
associated with the called 
procedure. 


Then to branch to the oneunit or the 
procedure. 


Linkage: 


RA: A(Parameter list) 

Parameter list: 
A(Entry parameter). The entry 
parameter is an 8-byte field 
containing: 


Ist word: On-unit or entry address 


2nd word: Invocation count of the DSA 


associated with either the 
passing procedure or the 
procedure in which the ON 
Statement was executed 


Called by: Compiled code, IHEERR 
Entry point IHETSAP 
Function: 
As IHETSAA, but also passes a PARM 


parameter from the the EXEC card. 
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Linkage: 


L(PRV) from IHESIZE 
L(LWS) from assembly of IHELIB 


Called by: Initial entry 


Entry point IHETSAR (RETURN) 


Function: 


Frees all chain elements up to and 
including the last procedure DSA in the 
chain. Terminates the main procedure 
and subtasks as in IHETSAE. 


Linkage: None 
Called by: Epilogues 


Entry point IHETSAT 


Function: 


To implement a CALL statement with a 
task option: 


1. Completes the parameter list 
(reserved fields) 


2. Requests control task to attach 
subtask. 


Linkage: 


RA: A(Parameter list) 

Parameter list: 
A(Task variable) (Byte 0 = x'80' if 
no PRIORITY option; bytes 1 - 3 = 0 
if no TASK option) 
A(Event variable) (Zero if no EVENT 
option) 
Relative priority 
A(Called procedure) 
Reserved 
Reserved (X'80' if no argument list) 
Variable length argument list for 
called procedure (Omitted if no 
argument list: X‘'80° in first byte of 
last word indicates end of list.) 


Called by: Compiled code 
Entry point IHETSAV (Get VDA) 
Function: 


To get a VDA for compiled code; sets 
RA=A(VDA). 


Linkage: 
RO: Length of VDA (excluding control 
words ) 
DR: A(Current save area) 


Called by: Compiled code 
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Entry point IHETSAW (Get Library VDA) 
Function: 
To provide a VDA for library modules 
and to set RA = A(VDA) 


Linkage: 


RO: Length of VDA (including control 
words) 


Called by: Library modules 
Function: 
Function: 


STAE exit routine. Enqueues on control 


task if necessary. Requests detach of 
any subtasks, informs control task that 
task has abnormally terminated. 
Linkage: None 
Called by: Supervisor 
Entry point IHETSAY 
Function: 
Completes the implementation of STOP: 
closes all opened files, releases 
dynamic storage, and requests that all 
subtasks of the control task, including 
itself, be detached. 
Linkage: 
RA: Return code 
Called by: IHEDUM, IHETSS 
Entry point IHETSAZ 
Function: 
Abnormal end of task: closes all files 
opened in task, releases dynamic 
storage, and terminates the task and 
all subtasks attached by it. 
Linkage: 
RA: Return code 
Called by: IHEDUM, IHEERR, IHETSE 
IHETSE 
Calls: .IHEERR, IHETSA 


Entry point: IHETSEA 


Function: 
To abnormally terminate the current task, 


and to raise the FINISH condition if the 
current task is the major task. 


Linkage: None 

Called by: Compiled code 

IHETSS 

Calls: IHEERR, THETSA 

Entry point: IHETSSA 

Function: 
To raise the FINISH condition and 
abnormally terminate the PL/I program in 
a multitasking environment. 

Linkage: None 

Called by: Compiled code 

IHETSW 

Calls: IHEERR, IHEJXI 
Supervisor (FREEMAIN,POST,WAIT), IHEJXI, 


IHETSA, the I/O transmission module whose 
address is in the FCB. 


Entry point IHETSWA 


Function: 


To determine whether a specified number 
of events has occurred. If not, to 
wait until the required number is 
complete, and, in the case of I/O 
events, to branch to the I/0 
transmission module (which raises I/0 
conditions if necessary). This mcdule 
is used in a multitasking environment. 


Linkage: 


RA: A(parameter list) 
Parameter list: 


Word 1: 


1. If all events are to be waited 
on: 


Byte 0 = X'FF* 
Bytes 1-3 not used 


2. If a specified number (N) of 
events is to be waited on: 


Byte 0 = x"00' 
Bytes 1-3 = A(N) 


Subsequent words (one for each 
element or array event): 


1. Array event: 


Byte 0 = dimensionality 
Bytes 1-3 = A(ADV) 


2. Element event: 
Byte 0 = x*'00° 
Bytes 1-3 = A(CEVENT variable) 


(The high-order byte of the last 
argument indicates the end of the 
parameter list.) 
Called by: Compiled code 
IHEUPA 
Entry Point ITHEUPAA 
Function: 
To zero the real part of a complex 
coded data item and to return the 
address of the imaginary part. 
Linkage: 
RA: A(Source) 
RB: A(Source DED) 
WRCD: A(Imaginary part) 
Called by: IHEDCN, IHEDBN 
Function: 
To return the address of the imaginary 
part of a complex coded data item if 
Switch is on, and to zero the imaginary 
part if switch is off. 
Linkage: 
RA: A(Source) 
RB: A(Source DED) 
WSWA: Switch for update address only 
WRCD: A(Imaginary part) 
Called by: 


IHEDBN, IHEDCN, IHEDIA, IHELDI, IHEDID, 
IHEDIE, IHEDNC, IHEDOM, IHEVCS 


IHEUPB 
Calls: IHEDMA 
Entry Point IHEUPBA: 
Function: 
To zero the real part of a complex 


numeric field and to return the address 
of the imaginary part. 
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Linkage: 


RA: A(Source) 
RB: A(Source DED) 
WRCD: A(Imaginary part) 


Called by: IHEDCN, IHEDBN 


Entry Point IHEUPBB: 


Function: 


To return the address of the imaginary 
part of a complex numeric field if 
switch is on, and to zero the imaginary 
part if switch is off. 


Linkage: 
RA: A(Source) 
RB: A(Source DED) 
WSWA: Switch for update address only 
WRCD: A(Imaginary part) 
Called by: 


IHfZDBN, IHEDCN, 
LHEDOM, IHEVCS 


IHEDIA, IHEDID, IHEDIE, 


LHEVCA 
Entry Point: IHEVCAA 
Function: 
To define the attributes of arithmetic 
data in character form by producing a DED 
(flags, p, q). 
Linkage: 
RA: A(Target DED) 
WNCP: A(Start and end addresses of data 
to be analysed) 
Called by: 
IHEDIA, IHEDIM, IHEDOM, IHELDI 
IHEVCS 
Calls: 
IHEDMA, IHEDNB, IHEDNC, IHEUPA 
Entry point IHEVCSA 
Function: 
To direct the conversion of character 
representation of complex data to 
internal string data. The character 
data is first converted to coded 
complex, with attributes derived from 


the real and imaginary parts of the 
source data (according to the 


148 


arithmetic conversion package rules) 
and then converted to string. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(Start and end addresses of real 
data) 
A(Real DED) 
A(Start and end addresses of 
imaginary data) 
A(Imaginary DED) 
A(Target SDV) 
A(Target DED) 
A(Real FED) 
A(Imaginary FED). 


Called by: IHEDIM, IHEDOM, IHELDi 


Entry point IHEVCSB 
Function: 


As for IHEVCSA but the conversion is to 
coded complex only. 


Linkage: As for IHEVCSA 
Called by: As for IHEVCSA 
IHEVFA 
Calls: IHEVTB 
Entry point: IHEVFAA 
Function: 
Radix conversion: binary to decimal 
To convert long floating-point to packed 
decimal intermediate. 


Linkage: 


WINT: Long precision floating-point 
number 


Called by: IHEDMA 


IHEVFB 


Entry point: IHEVFBA 


Function: 


To convert a long precision 
floating-point number to a fixed~point 
binary number with specified precision 
and scale 

factor. 


Linkage: 


WINT: Long precision floating-point 
number 

WRCD: A(Target) 
A(Target DED) 


Called by: IHEDMA 
IHEVFC 


Entry point: IHEVFCA 


Function: 
To convert a long floating-point number 
to a floating-point variable with 
specified precision. 
Linkage: 
WINT: Long-precision floating-point 
number 


WRCD: A(Target) 
A(Target DED) 


Called by: IHEDMA 


LHEVFD 

Entry point: IHEVFDA - 

Function: 
To convert a fixed-point binary integer 
with scale factor to long precision 
floating-point. 

Linkage: 


RA: A(Source) 
RB: A(Source DED) 


Called by: IHEDMA 
ILHEVFE 
Entry point: IHEVFEA 
Function: 
To convert a floating-point number of 
specified precision to long precision 
floating-point. 
Linkage: 


RA: A(Source) 
RB: A(Source DED) 


Called by: IHFDMA 


IHEVKB 





Entry point: IHEVKBA 


Function: 
To convert a fixed- or floating-point 
decimal numeric field to packed decimal 
intermediate. 

Linkage: 


RA: A(Source) 
RB: A(Source DED) 


Called by: IHEDMA 
LHEVKC 
Entry point: IHEVKCA 
Function: 


To convert a sterling numeric field to 
packed decimal intermediate. 


Linkage: 


RA: A(Source) 
RB: A(Source DED) 


Called by: IHEDMA 
IHEVKF 
Entry point: IHEVKFA 
Function: 
To convert packed decimal intermediate to 
a decimal fixed- or floating-point 
numeric field with specified precision. 
Linkage: 
WINT: Decimal integer 
WSCF: Scale factor 
WRCD: A(Target) 
A(Target DED) 
Called by: IHEDMA 
Entry point: IHEVKGA 
Function: 
To convert packed decimal intermediate to 
a sterling numeric field with specified 
precision. 
Linkage: 
WINT: Decimal integer 
WSCF: Scale factor 
WRCD: A(Target) | 
A(Target DED) 


Called by: IHEDMA 
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IHEVPA 


Calls: IHEVTB 


Entry point: IHEVPAA 


Function: 
Radix conversion: decimal to binary 
To convert packed decimal intermediate to 
long precision floating-point. 

Linkage: 


WINT: Decimal integer 
WSCF: Scale factor 


Called ky: IHEDMA 


IHEVPB 
Entry Point: IHEVPBA 
Function: 


To convert packed decimal intermediate to 
an F format item. 


Linkage: 

WINT: Decimal integer 

WSCF: Scale factor 

WFDT: A(FED) 

WRCD: A(Target) 
Called by: IHEDMA 
IHEVPC 
Entry point: JIHEVPCA 
Function: 


To convert packed decimal intermediate to 
an E format item. 


Linkage: 
WINT: Decimal integer 
WSCF: Scale factor 
WFDT: A(FED) 
WRCD: A(Target) 
Called by: IHEDMA 
IHEVPD 
Entry point: IHEVPDA 
Function: 
To convert packed decimal intermediate to 


a decimal integer with specified 
precision and scale factor. 
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Linkage: 


WINT: Decimal integer 

WSCF: Scale factor 

WRCD: A(Target) 
A(Target DED) 


Called by: IHEDMA 
ITHEVPE 
Entry point: IHEVPEA 


Function: 
To convert an F/E format item to packed 
decimal intermediate. 
Linkage: 
RA: A(CSource) 
RB: A(€Source DED) 
WFED: A(FED) 


Called by: IHEDMA 


IHEVPF 

Entry point: IHEVPFA 

Function: 
To convert a decimal integer with 
specified precision and scale factor to 
packed decimal intermediate. 

Linkage: 


RA: A(Source) 
RB: A(Source DED) 


Called by: IHEDMA 
ITHEVPG 
Entry point: IHEVPGA 


Function: 
To convert a binary fixed- or floating- 
point constant to long precision 
floating-point. 7 

Linkage: 


WCNP: A(Beginning of constant) 
ACEnd of constant) 


Called by: IHEDMA 
IHEVPH 
Entry point: IHEVPHA 


Function: 


To convert a bit string constant with up 
to 31 significant bits to long precision 
floating-point. 

Linkage: 


WCN1: A(Beginning of constant) 
A(End of constant) 


Called by: IHEDMA 

IHEVOA 

Entry point: IHEVQAA 

Function: 
To convert a floating point number of 
specified precision to a fixed-point 
binary number with specified precision 
and scale factor. 

Linkage: 
RA: A(Source) 
RB: A(Source DED) 
RC: A(Target) 
RD: A(Target DED) 


Called by: Compiled code, IHEVQB 


IHEVOB 

Calls: IHEVQA, IHEVTB 
Entry point: IHEVQBA 
Function: 


To convert a decimal constant to a coded 
arithmetic data type. 


Linkage: 


RA: A(First character of constant) 

RB: A(Last character of constant) 

RC: A(Target) 

RD: A(Target DED) 

WFED: A(FED) if constant is part of F or 
E format input 

WSWB: Switches specifying type of source 
string 


Called by: IHEDCN, IHEDIA 
IHEVOC 
Calls: IHEVSC, IHEVSE 
Entry point: IHEVQCA 
Function: 
To convert some coded arithmetic data 


types to F or E format or character 
string. 


Linkage: 


RA: A(Source) 

RB: A(Source DED) 

RC: A(Target SDV) 

RD: A (Target DED) 

WFDT: A(FED) 

WSWB: Switches specifying type of target 
string 


Called by: IHEDNC, IHEDOA 


IHEVSA 


Entry point: IHEVSAA 


Function: 
To assign a fixed-length or VARYING bit 
string to a fixed-length or VARYING bit 
string. 

Linkage: 
RAs A(Source SDV) 
RB: A(Source DED) 


RC: A(Target SDV) 
RD: A(Target DED) 


Called by: Compiled code, IHEDIA, IHEDNB 


IHEVSB 


Entry point: IHEVSBA 


Function: 


To convert a fixed-length or VARYING bit 
string to a fixed-length or VARYING 
character string. 


Linkage: 


RA: A(Source SDV) 
RB: A(Source DED) 
RC: A(Target SDV) 
RD: A(Target DED) 


Called by: 


Compiled code, IHEDOB, IHEDOD, IHEDOE, 
IHELDO 


IHEVSC 


Entry point: IHEVSCA 
Function: 
To assign a fixed-length or VARYING. 


character string to a fixed-length or 
VARYING character string. 
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Linkage: 


RA: A(Source SDV) 
RB: A(Source DED) 
RC: A(Target SDV) 
RD: A(Target DED) 


Called by: 


Compiled code, IHEDIA, IHEDIB, IHEDID, 
IHEDIE, IHEDNC, IHEDOB, IHEDOD, IHELDI, 
ITHEVQC 


IHEVSD 


Entry point IHEVSDA 


Function: 


To convert a fixed-length or VARYING 
character string to a fixed-length or 
VARYING bit string. The ONSOURCE 
address is stored. 


Linkage: 


RA: A(Source SDV) 
RB: A(Source DED) 
RC: A(Target SDV) 
RD: A(Target DED) 
WODF: A(Source SDV) 


Called by: 


Compiled code, 
IHELDI 


IHEDIB, IHEDID, IHEDIE, 


Entry point IHEVSDB 


Function: 


As for IHEVSDA, but the ONSOURCE 
address is not stored. 


Linkage: 
As for IHEVSDA, but without WODF 
Called by: As for IHEVSDA 


IHEVSE 


Entry point IHEVSEA 


Function; 


To assign a fixed-length or VARYING 
character string to a pictured 
character string. The ONSOURCE address 
is stored. 


Linkage: 


RA: A(Source SDV) 
RB: A(Source DED) 
RC: A(Target SDV) 
RD: A(Target DED) 
WODF: A(Source SDV) 
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Called by: 


Compiled code, IHEDIB, IHEDID, IHEDIE, 
IHEDOB | 


Entry point IHEVSEB 
Function: 


As for IHEVSEA, but the ONSOURCE 
address is not stored. 


Linkage: 


As for IHEVSEA, but without WODF 


Called by: IHEDNC, IHEVQC 
IHEVSF 
Entry Point: IHEVSFA 


Function: 


To convert a fixed-length or VARYING bit 
String to a pictured character string. 


Linkage: 


RA: A(Source SDV) 
RB: A(Source DED) 
RC: A(Target SDV) 
RD: A(Target DED) 


Called by: Compiled code, IHEDOB 


IHEVTB 


Base address of table: IHEVTBA 


Function: 


This module is a table of long precision 
floating-point numbers representing 
powers of 10 from 1 to 70. It is used by 
the radix conversion routines IHEVPA, 
IHEVQOB, and IHEVFA. 


Linkage: 


Not called. Referenced as external data 
by IHEVPA, IHEVQB and IHEVFA. 


IHEXIB 
Entry point: IHEXIBO 
Function: 


x*#n, where x is real fixed-point binary 
and n is a positive integer. 


Linkage: 
RA: A(x) 
*RB: A(DED for x) 
RC: A(n) 
RD: A(Target) 
*RE: A(Target DED) 


Called by: Compiled code 
IHEXID 


Entry point: IHEXIDO 


Function: 

x*%*n, where x is real fixed-point 

decimal, and n is a positive integer. 
Linkage: 

RA: A(x) 

RB: A(DED for x) 

RC: A(n) 

RD: A(Target) 

RE: A(Target DED) 


Called by: Compiled code 


IHEXIL 
Entry point: IHEXILO 
Function: 


x**#n, where x is real long 
floating-point, and n is an integer. 


Linkage: 
RA: A(x) 
RB: A(n) 
RC: A(Target) 
Called by: Compiled code 
IHEXIS 
Entry point: IHEXISO 


Function: 


x##n, where x is real short 
floating-point, and n is an integer. 


Linkage: 
RA: A(x) 
RB: A(n) 
RC: A(Target) 
Called by: Compiled code 
IHEXIU 
Calls: IHEMZU 
Entry point: IHEXIUO 


Function: 


z**#n, where z is complex fixed binary and 
nis a positive integer. 


Linkage: 

RA: A(z) 

*RB: A(DED for 2) 

RC: A(n) 

RD: A(Target) 

*RE: A(Target) 
Called by: Compiled code 
IHEXIV 
Calls: IHEMZV 
Entry point: IHEXIVO 
Function: 


z**n, where z is complex fixed-point 
decimal and n is a positive integer. 


Linkage: 
RA: A(z) 
RB: A(DED for 2z) 
RC: A(n) 
RD: A(Target) 

*RE: A(Target DED) 
Called by: Compiled code 
IHEXIW 
Calls: IHEMZW 
Entry point: IHEXIWO 
Function: 


z**#n, where z is complex short 
floating-point, and nis an integer. 


Linkage: 
RA: A(z) 
RB: A(n) 
RC: A(Target) 
Called by: Compiled code 
IHEXIZ 
Calls: IHEMZZ 
Entry point: IHEXIZ0 


Function: 


z**n, where z is complex long 
floating-point, and n is an integer. 


Linkage: 
RA: A(z) 
RB: A(n) 
RC: A(Target) 


Called by: Compiled code 
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IHEXXL 


Calls: IHEEXL, IHELNL 


Entry point: IHEXXLO 
Function: 


x**y, where x and y are real long 
floating-point. 


Linkage: 
RA: Aly) 
RB: A(x) 


RC: A(Target) 
Called by: Compiled code 
IHEXXS 
Calls: IHEEXS, IHELNS 
Entry point: IHEXXS0 
Function: 


x**y, where x and y are real short 
floating-point. 


Linkage: 
RA: Aly) 
RB: A(x) 
RC: A(Target) 


Called by: Compiled code 


IHEXXW 
Calls: IHEEXW, IHELNS, IHELNW 
Entry point: IHEXXWO 


Function: 


Zo**z2, where z, and zz are complex short 
floating-point. 


Linkage: 
RA: A(za) 
RB: A(z,) 


RC: A(Target) 
Called by: Compiled code 
ITHEXXZ 
Calls: IHEEXZ, IHELNL, IHELNZ 
Entry point: IHEXXZ0 
Function: 
Za**Z5, where Z, and Zag are complex long 


floating-point. 
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Linkage: 


RA: A(z2) 
RB: A(z,) 
RC: A(Target) 


Called by: Compiled code 


LHEYGF 


Calls: 


Entry point IHEYGFV 


Function: 


POLY (A,X) for both A and X vectors of 
real fixed-point binary or decimal 
numbers. Result is real short or long 
floating-point. 


Linkage: 


RA: A( Parameter list) 
Parameter list: 
A(ADV of argument 1) 
A(DED of argument 1) 
A(ADV of argument 2) 
A(DED of argument 2) 
A(Target) 
A(DED of target) 


Called by: Compiled code 


Entry point IHEYGFS 


Function: 


As for IHEYGFV but X is scalar. 


Linkage: 


RA: A( Parameter list) 
Parameter list: 
A(ADV of argument 1) 
A(DED of argument 1) 
A(Argument 2) 
A(DED of argument 2) 
A( Target) 
A(DED of target) 


Called by: Compiled code 


IHEYGL 
Entry point IHEYGLV 
Function: 
POLY (A,X) for both A and X vectors of 


real long floating-point numbers. 
Result is real long floating-point. 


IHEDMA wn 


Linkage: 
RA: A(Parameter list) 
Parameter list: : 
A(ADV of argument 1) 
A(ADV of argument 2) 
A(Target) 


Called by: Compiled code 


Entry point IHEYGLS 


Function: 


As for IHEYGLV but X is scalar. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(ADV of argument 1) 
A(Argument 2) 
A(Target) 


Called by: Compiled code 


IHEYGS 


Entry point IHEYGSV 


Function: 
POLY (A,X) for both A and X vectors of 


real short floating-point. Result is 
real short floating-point. 


Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(ADV of argument 1) 
A(ADV of argument 2) 
A(Target) 


Called by: Compiled code 


Entry point IHEYGSS 


Function: 


As for IHEYGSV but X is scalar. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(ADV of argument 1) 
A(Argument 2) 
A(Target) 


Called by: Compiled code 


IHEYGW 


Entr Oint IHEYGWV 


Function: 


POLY (A,X) for both A and X vectors of 
complex short floating-point. Result 
is complex short floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(ADV of argument 1) 
A(ADV of argument 2) 
A( Target) 


Called by: Compiled code 


Entry point IHEYGWS 


Function: 
As for IHEYGWV, but X is scalar. 
Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(ADV of argument 2) 
A(Argument 1) 
A(Target) 


Called by: Compiled code 
IHEYGX 


Calls: IHEDMA 


Ent r oint IHEYGXV 


Function: 


POLY (A,X) for both A and X vectors of 
complex fixed-point binary or decimal 
numbers. Result is complex short or 
long floating-point. 


Linkage: 


RA: A(Parameter list) 
Parameter list: 
A(ADV of argument 1) 
A(DED of argument 1) 
A(ADV of argument 2) 
A(DED of argument 2) 
A(Target) 
A(DED of target) 


Called by: Compiled code 
Entry point IHEYGXS 
Function: 


As for IHEYGXV, but X is scalar. 
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Linkage: 


RA: A(Parameter list) 

Parameter list: 

- A(CADV of argument 1) 
A(DED of argument 1) 
A(Argument 2) 

A(DED of argument 2) 
A(Target) 
A(DED of target) 


Called by: Compiled code 
IHEYGZ 
Entry point IHEYGZS 
- Function: 
As for IHEYGZV, but X is scalar. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(ADV of argument 1) 
A(Argument 2) 
A(Target) 
Called by: Compiled code 
Entry point IHEYGZV 
Function: 
POLY (A,X) for both A and X vectors of 
complex long floating-point numbers. 
Result is complex long floating-point. 
Linkage: 
RA: A(Parameter list) 
Parameter list: 
A(ADV of argument 1) 
A(ADV of argument 2) 
A(Target) 


Called by: Compiled code 
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IHEZZC 
Calls: IHEZZF 


Entry point: IHEZZCA 


Function: 
To provide a SNAP dump with save-area 
trace and information about the PL/I 
files that are open. 

Linkage: 
RA: A(Parameter list) 


See source listing for parameter list. 


Called by: IHEDUM 


LHEZZF 


Entry point: IHEZZFA 


Function: 


To provide the save-area trace that forms 
part of the output produced by IHE2ZC. 


Linkage:. 


RA: A(Parameter list) 
See source listing for parameter list. 


Called by: IHEZZC 


APPENDIX As SYSTEM MACRO INSTRUCTIONS 


The following table lists the system macro instructions used by the PL/I library and 
associates their use with individual library modules. 


System Macro Library Module 


ABEND IHEDUM, IHEERR 

ATTACH IHETSA 

CHAP IHECTT, IHEIGT, IHEITB, IHEITC, IHEITH, IHEITJ, IHEITO 

CHECK IHEITF, IHEITJ, IHEOP2, IHEITB, IHEITC 

CHKPT IHECKP 

CLOSE IHECTT, IHECLS, IHECLT, IHEOP2 

DCB IHEOPO, IHEOPZ 

DCBD IHECLT, IHECTT, IHEITB, IHEITC, IHEITD, IHEITE, IHEITF, IHEITG, IHEITH, 
IHEITJ, IHEOCL, IHEOCT, IHEOPO, IHEOPP, IHEOPQ, IHEOPZ 

DELETE IHECLT, IHECTT, IHEESM, IHETEX 

DEQ IHECTT, IHEDDT, IHEESM, IHEIBI, IHEITH, IHEITJ, IHEOCT, IHEPTT, IHETSA, 
IHETEX, IHEITO 

DETACH IHETSA 

DEVTYPE IHEOPO 

ENQ IHEDDT, IHEESM, IHEIBT, IHEITH, IHEITJ, IHEOCT, IHEPTT, IHETEX, IHEITO 

ESETL ‘IHEITD 

EXTRACT IHETSA, IHETEX, IHETOM, IHEPRI, IHEPTT 

FREEMAIN IHEBEG, IHECLT, IHECTT, IHEDSP, IHEIOG, IHEITB, IHEITC, IHELSP, IHEMSW, 
IHEOCL, IHEOPZ, IHEOSW, IHESAP, IHETCV, IHETSA, IHESRT, IHETSW 

FREEPOOL IHECLT, IHECTT, IHEOPQ, IHEOPZ 

GET IHEITD, IHEITG, IHEITP 

GETBUF IHEOPZ 

GETMAIN IHEBEG, IHEDSP, IHEERR, IHEIG?, IHEIOG, IHEITB, IHEITC, IHEITD, IHEITE, 
IHEITF, IHEITH, IHEITJ, IHEITP, IHELSP, IHEOPO, IHEOPP, IHEOPQ, IHEOPZ, 
IHESAP, IHETCV, IHESRT, IHETSA 

GETPOOL IHEOPP 

LINK IHEBEG, IHEDUM, IHEERR, IHEOCL, IHEOCT, IHEOPN, IHESRT, IHETSA 

LOAD IHEESM, IHEOPQ, IHETEX 

OPEN IHEOPP, IHEOPZ 

POST IHEDSP, IHEDUM, IHEIGT, IHEINT, IHEITB, IHEITC, IHEITH, IHEITJ, IHEOCT, 
IHETEA, IHETEV, IHETPR, IHETSA, IHETSW 
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System Macro 
PUT 


PUTX 
READ 
RETURN 
SETL 
SNAP 
SPIE 
STAE 
STIMER 
TIME 


WAIT 


WRITE 


WTOR 


XCTL 
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Library Module 


IHEITD, 
IHEITD, 
IHEITB, 
IHECLT, 
IHEITD 

IHEDUM 

IHEERR, 
IHESAP, 
LHEOSI 

IHEOSD, 


IHEDSP, 
IHEMSW, 


IHEITB, 
IHEITN, 


IHEDSP, 
IHEDSP 


IHEOPN, 


crate peer gees 


IHEITG, 
IHEITG 
IHEITE, 


IHECTT 


IHESAP, 


IHESTA 


IHEOST 


IHEDUM, 
IHEOCT, 


IHEITC, 
IHEITO 


IHEOCL, 


IHEOPO, 


IHEITP, 


IHEITF, 


IHESRT, 


IHEIGT, 
IHEOSW, 
IHEITE, 


IHEOCT, 


IHEOPP 


LIHETEX 


IHEITEH, 


IHETSA 


IHEINT, 
ITHETEA, 


IHEITF, 


IHEPRT, 


IHEITJ, 


IHEITB, 
IHETEV, 


IHEITH, 


IHETOM, 


IHEITK, 


IHEITC, 
IHETPR, 


IHEITJ, 


IHETEX, 


IHEITM, 


IHEITN, IHEITO 


IHEITE, IHEITH, IHEITJ, 
IHETSA, IHETSW 


IHEOPZ, IHEITL, IHEFITM, 


IHEPTT 


System Generation Process 


IBM System/360 Operating System consists of 
libraries of program modules that can be 
united in a variety of combinations, 
according to options specified by the user. 
The user selects the programming options 
that meet his data processing requirements 
and conform to his machine facilities. The 
selected options are translated into 
program module requirements by the system 
generation process, the modules being 
compiled into libraries that form the new 
operating system. 


The operating system is generated in two 
stages. First, a series of user-supplied 
macro instructions, which describe the 
machine facilities and programming options 
required, is written. From these, if no 
errors are found, a job stream is 
generated. In the next stage, the ‘job 
stream is processed by the assembler, the 
linkage editor, and utility programs, to 
generate the libraries of modules which 
form the new operating system. The whole 
process is carried out using an existing 
operating system. The system generation 
process is described in IBM System/360 


Operating System: System Generation. 


PL/I Library System Generation 


All PL/I library modules are in load module 
form. Before system generation they exist 
on two libraries on the starter system: 


1. SYS1.PLILIB. This PDS contains 
modules which are always required by 
a system using PL/I. 


2. SYS1.LM512. This contains both 
modules which are optionally 
required and modules which will be 
copied into SYS1.LINKLIB. 


Three PL/I library system macros are used, 
whose purpose is to produce COPY control 
cards for inclusion in the job stream. 


The first macro, SGIHESLA, produces COPY 
control cards to copy modules from 
SYS1.LM512 into SYS1.LINKLIB. 


The second macro, SGIHE5PB, produces 
COPY control cards to copy the non-optional 
modules on the starter system SYS1.PLILIB 
into the new SYS1.PLI1LIB. 


‘sy 
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The third macro, SGIHESPC, tests for the 
COMPLEX arithmetic option. If it is 
present, COPY control cards are produced 
for modules dealing with complex arithmetic 
(about 30% of the total number). The macro 
then tests to see if the TIME and STIMER 
options have been requested and are 
available. If so, COPY control cards are 
produced for IHEOST and IHEOSI. If either 
or both of these options are not required, 
either or both of the dummy modules IHEMST 
and IHEMSI are renamed IHEOST and IHEOSI 
respectively and the appropriate COPY 
control cards are produced. Similarly, if 
the MULTIPLE WAIT option is not requested, 
the SINGLE WAIT module IHEMSW is renamed 
IHEOSW. 


STORAGE UTILIZATION AND SHARED LI PRARY 


ES A EE CEE I 


Users of MVT and MFT control programs 
within the operating system may use the 
shared library feature in which parts of 
the re-entrant PL/I library are resident in 
the operating system. Phis feature enables 
certain modules to be shared between 
partitions or regions, thus greatly 
reducing the storage requirements of an 
individual PL/I program within a partition 
or region. 


Transfer of control between each 
partition and the resident library is 
achieved by means of two transfer vector 
modules, IHELTV and IHELTT. The module 
IHELTT is link-edited to the PL/I program 
and controls the calis to the resident 
library. IHELTV is link-edited to the 
resident library and controls the calls to 
the partition. Correlation between the two 
transfer vector modules is maintained by 
the PRV in each partition. Therefore, 
standardisation of the PRV is implicit in 
this feature. 


Practical implementation of the shared 
library feature necessitates separation of 
the library modules into functional groups. 
These groups are selected by options in the 
SYSGEN PL1LIB macro and are listed in Table 
1. This list includes those modules which 
May not be made resident (i.e., not 
shareable) and these are placed in Group 1. 
The storage management modules (group 2 or 
3) will always be included in a resident 
library. Tables 2 through 9 show the 
modules in their respective "packages" with 
their associated group numbers, whilst 
Table 10 is an alphabetical cross-reference 
list of the modules. 
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The Shared Library feature is made 
available at system generation time by 
specifying the required options in the 
PLILIB macro. The specification of these 
options governs the generation of the 
resident load modules IHELTTA and IHELTVA. 


Table 1. Grouping of Modules (Shared 
Library Feature) 

|Group| ; 

{| No. | Main Functions of the Group | 

}—-_-_4 -_ + -- —— = 


| 
2 |Multi-tasking storage management | 
3 |Non-tasking storage management | 
4 |Exrror handler (ON-units) | 
5 |List processing and structure | 
| mapping { 
6 |Basic conversion package | 
7 jEdit conversions | 
8 |Complex conversions | 
9 |Bit string conversions | 
10 |Character string conversions | 
11 |Picture conversions | 
12 |Sterling conversions | 
13 jOptimization=1 special conversions | 
14 |Bit string functions | 
15 |Character string functions { 
16 |*STRING' BIF and PV | 
17 |Real non-interleaved arrays | 
18 |Real interleaved arrays | 
|Complex non-interleaved arrays | 
20 |Complex interleaved arrays | 
21 |Real arithmetic operators | 
22 |Complex arithmetic operators | 
23 |Real short arithmetic functions | 
24 |Real long arithmetic functions | 
25 |Complex short arithmetic functions | 
26 |Complex long arithmetic functions | 
27 |Non-tasking data-directed I/0 | 
28 |Non-tasking list-directed I/0 | 
29 |Non-tasking edit~directed 1/0 | 
30 |Multi-tasking data-directed I/0 | 
31 |Multi-tasking list-directed I/0 | 
32 |Multi-tasking edit~directed I/0 | 
33 |Non-tasking record I/0 | 
34 |Multi-tasking record I/0 | 
35 |Non-tasking record I/O wait | 
36 |Multi-tasking record I/O wait | 
Acai Ba aie i ee eee meas 
Notes The non-shared modules (Group 1) 
comprise those modules from the 
Housekeeping, String Function, and STREAM 
I/O Packages which cannot reside in the 
shared library. 


- 
wo 


IHELTVA consists of the resident 
transfer vectors plus all the library 
modules selected for residency; the latter 
are link-edited to IHELTVA. IHELTTA 
consists of the non-resident transfer 
vectors. At initial program load time, the 
load module containing IHELTVA must be made 
resident in the link pack area of MVT or 
the resident access methods area of MFT 
control programs. 
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Module IHELTTA must be included when a 
user wishes to create the shared library 
feature, and this may be achieved by means 
of the catalogued procedures discussed in 
IBM System/360 Operating System: PL/I (F) 
Programmer's Guide. 


For details of the PLILIB macro 
instruction, see IBM System/360 Operating 
System: System Generation. Main storage 
requirements for this feature are discussed 


in IBM System/360 Operating System: Storage 
Estimates. 


Table 2. Housekeeping Package 


=i RETEST, 
{ | Group Number | 
{Module | Description oe 
| f2 $2 43 14 [5 | 
}------}-------------------}--4--4--4--}--4 
| IHEABN| ABEND option |x 


bt | tf 
|IHETCV] Control Variable | } | | f 
| IHETEA| Event Variable i middie 4 
| IHETER| ON Field 1 (| t 
| IHETEV| COMPLETION ; smetd4ieio 
| IHETPB| PRIORITY rsixdlddd 
{| IHETPR| PRIORITY ;smid$eidyp od 
| IHETSA| Storage Manag.t ; xy dd 4 
| IHETSE| FINISH 1 md |st od 
| IHETSS| FINISH ae an (ee Qe | 
{| IHESAP] Storage Manag.t 1 | Ud dt 4 
|IHEOSS| FINISH 1 to oumetoqpd 
{| IHEOSE| EXIT ip tomet dod 
| IHECKP| Checkpoint iIxt | doy 
| IHEDSP| Display xisedtit=#o4 
| IHEDUM| Dump ; myexd dt 4 
| IBESRT| Sort xdoedteiep 
| IHEERR| Error ; mixd td 4d 
| IHECFA| ONLOC ;didgiedod 
| IHECFB| ONCODE i tbouexd 4 
| IHECNT] ONLINE ns es nn © <n 
| IHEOCL| OPEN/CLOSE ;4eemxddtd 
| | (non-tasking) | | | | ft 1 
| IHEOCT] OPEN/CLOSE 1 melee 
| | (multitasking) | {| | { 4 1 
| IHESRC| ONSOURCE iy’eieueudo4 
| IHESRD| ONKEY 1 | &@ Ua 
| IHELSP| List Processing 1 | | | U4 
|IHESTR| Structure Mapping | | | | IX | 
| IHEBEG| Terminal Error xidd 4 
| IHECFC| Mod 91 and 195 xd@bid#bp ¢ost 
| | interrupts ttt 
{ IHEM91| Mod 91 and 195 ix} ddd 4 
| errors rt tt tel 
| IHEMAI| Main xi ddd 4 
| IHEMSI| No Timer ix} ¢ ¢ § | 
|IHEMST| No TIME ix! dg ddd 
{| IHEMSW| WAIT I/O Event xi ddd 
| IHEOSD| Date ; s@axqyexd |of 
| IHEOSI| Delay xi dddo4 
| IHEOST| Time ; ixuxd fool 
| IHEPTT| COPY Tasking 1 mei | 44 
JIHEPRT| COPY Non-tasking | | {xX | {| 
| IHERES| Restart xidt to 
| IHESIZ| Length PRV iIxi ft ¢ & 4 
| IHESPR| SYSPRINT DCLCB aan ee ee (fe 
ns ne oe a ae Ge eee | 
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Table 3. Conversion Package 

aaa aaa a a a a ahaa aa | 
[ i | Group Number { 
| Module | Description ponnn— yore Yo yen ry mr rrp rr rnp rn err 
| ;} 6 | 7 | 8 | 9 Jf 10] WY 4 | 13 | 
}--—----- —------ == --- = --- } += --} ----- =f ff ft 
| IHEDIA | F format director |} x | xX | | | | | | x | 
| IHEDIB | E to Internal | ; x | | ; x | | | | 
|] IHEDID | B to Internal | | x | }; x | | | | | 
| IHEDIE | Picture to Internal | i; x | | | ; x | | { 
| IHEDIL | A/B error | | | x |] | | | | | | 
| IHEDIM {| C to Internal | ; x | | | | i | | 
{ IHEDOA | Internal to F/E ; x | x | | | | | ; x | 
{| IHEDOB | Internal to A | } x | | { | j | | 
| IHEDOD | Internal to B | 1 x | | | i | | | 
| IHEDOE | Internal to Picture | ; x | { | ; x | | | 
"| IHEDOM | Internal to Cc | 1 x | [ | | i 
| IHEDMA | Conversion director | x | xX | xX | X | xX J XxX | | | 
| IHEDNB | Arithmetic to Bit | | ; x | | | | | 
| IHEDBN | Bit to Arithmetic | | | ! ; x | | | | | 
| IHEDCN | Bit to Character | | | | ; x | | i | 
| IHEDNC | Arith to Character | | | | ; x | | i} x | 
| IHEKCA | Valid Dec. Picture i | | { } x | 1 x | 
| IHEKCB | Valid Sterling Picture | | | | | ] | 
| IHEKCD | valid Char. Picture i | | ; x | | | | 
| IHEUPA | Address Real Complex | | }; x | | | | | | 
| IHEUPB | Address Imag. Complex | | |} x | | j; x | } | 
| IHEVCA | Arith. attributes | { ; x | | { | { | 
| IHEVCS | Complex to Internal | | | x | | | | | | 
| IHEVFA | Binary to Decimal } x | | x | | } x | | | 
| IHEVFB | Float to Fixed }; x | } x | ; 1} x | | | 
| IHEVFC | Float to Float ;} x | | [ { | | | | 
| IHEVFD | Fixed to Float ; x | } x | | } x | | | 
| IHEVFE | Float to Float ; x | { | | | | | { 
| IHEVKB | Decimal to Packed | | | | | ; x | | | 
| IHEVKC | Sterling to Packed | | | { | | | | | 
| IHEVKF | Packed to Fixed | | | | | } x | | | 
| IHEVKG | Packed to Sterling | | | | | | ] | | 
| IHEVPA | Decimal to Binary ; x | } x | | ; x | | | 
| IHEVPB | Decimal to F | x | ; x | | ; x | | | 
| IHEVPC | Packed to E }; x | } x | | ; x | | | 
| IHEVPD | Packed to Decimal }; x | i; x | | ; x | | | 
‘| IHEVPE | E/F to Packed {| x | i} x | | j x | | | 
| IHEVPF | Decimal to Packed |} x | i x | i }; x | | | 
{| IHEVPG | Fixed to Float | | | | ; x | | | | 
| IHEVPH | Bit to Float | | } , x | i | | | 
| IHEVSA | varying Bit | | | 1 x | | 
| IHEVSB | Varying Bit/Character | | | i x {| x | | | | 
| IHEVSC | Varying Character { | | | ; x | | | | 
| IHEVSD | Varying Bit/Character | | | ; x | xX | ] | | 
| IHEVSE | Character to Picture | | | | ; x | j | } 
| IHEVSF | Bit to Picture | | i 1 x | x | ] | | 
| IHEVQA | Float to Fixed | ; | | | | | |; x | 
| IHEVQB | Decimal to Arithmetic | | i | | | | } x | 
| IHEVQOC | Arith. to E/F/Char. | i { | i { ; x | 
bec eos se ee eae eet ) eS a a a eae eee aes eee 
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Table 4. STRING Function Package 
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ae ear ee ne ee ene eee ae en 

( i Group Number | 
| Module | Description } ——---- 4 oe pn | 
| | ; 1 | Wy 5 | 16 | 
}--------}---------—------------} ----- }-----+-----}--—--4 
| IHEBSA | And | ; x | | | 
| IHEBSO | Or | | x | | | 
| IHEBSN | Not | t x | | | 
| IHEBSC | Compare | | x | ; | 
| IHEBSM | Assign | | x | | | 
| IHEBSK | Concat, REPEAT | ; x | | | 
| IHEBSD | Compare | }; x | | | 
| IHEBSS | Compare, SUBSTR | ; x | | | 
| IHEBSI | INDEX | } x | | | 
| IHEBSF | BOOL | ; x | | 
| IHEBSV | VERIFY | | | | | 
| IHEBST | TRANSLATE | | | | 
| IHECSK | REPEAT | | ; x | | 
| IHECSC | Compare | | {| x | | 
| IHECSM | Assign, Fill HIGH/LOW | | | x | 
} IHECSS | SUBSTR | | } x | 
{| IHECSI | INDEX | | ; x | | 
| IHESTG | STRING BIT | | 1 x | 
| IHESTP | STRING PV | | | | x | 
| IHECSV | VERIFY | { x | | 
| IHECST | TRANSLATE | | x | | 
bf Ene sae EP pe ae ee recep eS eRe aren Qt ee Decree bees 
Table 5. ARRAY Function Package Table 6. Arithmetic Function Package 
(SPSS ee ee a ee 7 SSS ==225> Se 
| i | Group Number | | | | Group Number | 
| Module | Description }--—--y----y----7---4 | Module | Description }------ ----—-- | 

|} 17 | 18 | 19 | 20] j | {| 21 | 22 | 

}-----—-- }-—---------—-} --——} ----}-—--}---] |--------} -------------------}------ 
| IHEJXS | Indexer 1x |x [ xt | IHEXIB | X##N x | | 
| IHEJXI | Indexer | (x | |x] {| IHEXID | X##N | x | | 
| IHENL1 | ALL ANY (x | xX | xX |x | IHEAPD | X*#N i x | | 
] IHENL2 | ALL ANY | ; x | {| x | | IHEXIS | X*#N {| x [ | 
{| IHESSF | SUM |x | | | | | IHEXXS | Shift } x | | 
| IHESMF | SUM | 1} x | | | | IHEXIL | X**y | x | | 
| IHESSG | SUM , x | 1x | 4 | IHEXXL | X#*#*y } x | | 
| IHESMG | SUM | 1x | | x | | IHEMZU | X#Y X/Y | 1 x | 
| IHESSG | SUM (x | {x | | | IHEXIU | X#*#N | 1 x | 
| IHESMH | SUM | | x | ix | | IHEMZV | X#¥ X/Y { | x | 
| IHEPSF | PROD 1x | | | | | IHEXIV | X*#N | ; x | 
| IHEPDF | PROD ; x | | | | IHEMZW | X#*Y — | 1 x | 
{| IHEPSS | PROD ;x | | | | | IHEDZW | X/Y { 1 x | 
{| IHEPDS | PROD | 1x | | { IHEXIW | X##N 1 x | 
| IHEPSL | PROD 1x | | | | | IHEXXW | X##*y { 1 x | 
| IHEPDL | PROD | 1x | | { | IHEMZ2 | X*y { i x =| 
| IHEYGF | POLY x | x | | | IHEDZZ | X/Y { { x | 
| IHEYGS | POLY ;x | x | { | | IHEXIZ | X*#N | 1 x | 
| IHEYGL | POLY ;x |x | | | IHEXXZ | X#*y { i x =| 
| IHESSX | SUM | | }x | | | IHEMXB | MAX MIN i; x | 
{ IHESMX | SUM | | | 1 x | | IHEMXD | MAX MIN ; x | | 
| IHEPSX | PROD | | ; x | | | IHEADD | ADD |} x | | 
| IHEPDX | PROD | { | x | | IHEMXS. | MAX MIN ; x | | 
| IHEPSW | PROD | | |x | | | IHEMXL | MAX MIN j; x | | 
| IHEPDW | PROD | | | | X | © | IHEMPU | MULTIPLY { | x | 
| IHEPSZ | PROD | {|x | { | IHEDVU | DIVIDE | ; x | 
| IHEPDZ | PROD i | | 1 x | | IHEADV | ADD | ; x | 
| IHEYGX | POLY | 1x |x] | IHEMPV | MULTIPLY ; x | 
{ IHEYGW | POLY | | ,x | x | | IHEDVV | DIVIDE | ; x | 
{ IHEYGZ | POLY ; | {x | x | l--—--——— Wt --—-- 1-1 -- = J 
ae , as en Seas Keene Cee 


Table 7. Mathematical Function Package Table 8. RECORD I/O Package 
6S re ee ee ee 
| | fereoe Number | | | {Group Number| 
| Module | Description bey -- 7 --—-4 | Module | Description bape 
i | [23124] 25| 26 | | | | 33)/34(35|36| 
}~----——- }----------------}--}--}--f-—- 4 f----- f ---------- = te 
| IHESQS | SQRT 1x |] |x | | {| IHEION|I/O transmitter route| X | | | | 
| IHEEXS | EXP 7 | |x | | | IHEOSW|Wait I/O EVENT { Ix || 
| IHELNS | LOG ix | x | | | IHEOCL | OPEN/CLOSE | ixi std 
| IHESNS | SIN COS Ix | |x { { {IHEINT|I/O transmitter route| Ix} otf 
| IHETNS | TAN xX | qx | |  |IHETSW|Wait I/O EVENT ] i | «id 
| IHEATS | ATAN Ix |] x | | | IHEOCT | OPEN/CLOSE Ix? otf 
| IHESHS | SINH COSH x | Ux | J bee db  -- -- - -- -- -- +--+ ddd 
| IHETHS | TANH xX | |x | | 
| IHEHTS | ATANH 1x | |x | | 
| IHEEFS | ERF IX |} |x | | 
| IHESQL | SQRT ; (xf [x | 
| IHEEXL | EXP i xqtiox if 
| IHELNL | LOG oxidise | 
| IHESNL | SIN COS 1 yxy qx | 
| IHETNL | TAN | m= | yx 4 
| IHEATL | ATAN {| [xX | Ux | 
| IHESHL | SINH COSH | xyux | 
| IHETHL | TANH 1 ix dt Ux 4 
| IHEHTL | ATANH | axyiqux | 
| IHEEFL | ERF | xd ox 
| IHESQW | SORT f | xt | 
| IHEEXW | EXP i; st yx | | 
| IHELNW | LOG 1 | (% | ; 
| IHESNW | SIN COS SINH COSH | | {X | [ 
| IHETNW | TAN TANH i | xf | 
| IHEATW | ATAN ATANH pt xd f 
| IHESQZ | SQRT 1 | t Ux | 
| IHEEXZ | EXP i | dos 
| IHELNZ | LOG i | ¢ kd 
| IHESNZ | SIN COS SINH COSH | | | [Xx | 
| IHETNZ | TAN TANH i |oqgsqex | 
| IHEATZ | ATAN ATANH i ft dt YX 
| IHEABU | ABS i | «xd { 
| IHEABV | ABS i « x 4 | 
| IHEABW | ABS lt | to ft 
{ IHEABZ | ABS i | gosqEx 4 
a ee ea [ a een ek os cae cee 
Table 9. STREAM I/O Package 
arses ee a ee ee ne ee ee ne 
Group Number i 
{| Module | Description rig ra re carne ae ao 
| | | 1 | 27 | 28 | 29 | 30 | 32 | 32 | 
}--—----~}-—------------------ 4----f---- -—--} ---- f- ---} -—_-—-4 
| IHEDDI | Read Data { ix | | ix | { 
| IHEDDO | Write/Convert Data | ; x | | | | | | 
{| IHEDDJ | Array/address j |x | | | x | | i 
| IHEDDP | Array subscript | |x | | | x | | { 
| IHEDDT | Write Data Tasking | | | | {x | | | 
| IHEIBT | Tasking PUT j | [ }x | xX | xX | 
| IHEIOA | GET ix ~x | xX | XK |X |x | 
| IHEIOB | Non-tasking PUT { |} x | X | xX f | | | 
| IHEIOC | GET string |} x | | | | | | | 
| IHEIOD | Datafield handler | | | |x |f | }x | 
| IHEIOF | Logical records | 1x | xX | X | KX | X | XxX | 
| IHEIOP | Page/Skip/Line ; ix |x | xX JT xX |X YX | 
| IHEIOX | Skip/Column | | | | x | | {x | 
| IHELDI | Read List | | (x | | {x | | 
| IHELDO | Write/Convert List | | {| x | i jx | | 
| IHETAB | Page/Line default | };x | x | }x {x | | 
tee hee ee ee a ee ed ook J 
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Table 10. Cross-Reference to Library 
Modules and Groups 


a SR APIS TI SET I SRG cc a aac aan | 
{Module Name | Selected Group | 
}-----~------ f---------------=------------4 
| IHEABN | 1 | 
| IHEABU | 25 | 
{| IHEABV | 25 r 
| ITHEABW { 26 | 
| IHEABZ [ 26 | 
{| IHEADD | 21 
| IHEADV | 22 ; 
| IHEAPD | 21 | 
| IHEATL | 24, 26 | 
| IHEATS | 23,25 | 
{| IHEATW | 25 i 
| IHEATZ | 26 | 
| IHEBEG | 1 | 
| IHEBSA | 18 { 
| IHEBSC | 18 | 
{ IHEBSD | 14 \ 
; ITHEBSF { 14 | 
| IHEBSI | 14 | 
{ IHEBSK | 14 i 
{ IHEBSM i 14 | 
{ IHEBSN | 14 | 
| IHEBSO | 14 | 
i IHEBSS |{ 14 i 
| IHEBST | 1 | 
| IHEBSV | 1 { 
| IHECFA | 4 i 
{ IHECFB | 4 | 
| IHECFC | 1 | 
| $IHECKP | 1 i 
| IHECLT | #LINKLIB | 
| IHECNT {| & | 
( IHECSC | 15 j 
| IHECSI | 15 | 
| IHECSK | 15 i 
{ IHECSM | 15 i 
| IHECSS | 15 i 
{ IHECST | 15 | 
| IHECSV | 15 | 
| IHECTT { LINKLIB | 
| IHEDBN | 9 | 
| IHEDCN | 10 | 
| IHEDDI | 27,30 { 
| IHEDDJ | 27, 30 | 
| IHEDDO | 27 | 
{ IHEDDP | 27, 30 | 
| IHEDDT | 30 | 
j IHEDIA | 6,7,13 | 
t IHEDIB | 7,10 | 
| IHEDID | 7,9 i 
| IHEDIE i 7,11,12 | 
| IHEDIL | 7 | 
| IHEDIM | 7 | 
| IHEDMA | 6,7,8,9,10,11,12 | 
| IHEDNB | 9 | 
| IHEDNC | 10,13 i 
| IHEDOA | 6,7,13 | 
| IHEDOB | 7 { 
| IHEDOD | 7 | 
| IHEDOE | 7,11,12 | 
| IHEDOM | 7 | 
| IHEDSP ] 1 | 
| IHEDUM {| 2,3 | 
bs es Le i ee ee eee ee ed 
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{Module Name | 


Selected Group | 


}------------}--------------——----- ——---—--| 
{ IHEDVU | 22 | 
{| IHEDVWV | ~~ 22 | 
{| IHED2W | 22 | 
| IHEEFL | 24,26 
| IHEEFS | 23,25 | 
| IHEERD |  LINKLIB | 
| IHEERE |  LINKLIB 
| IHEERI |  LINKLIB | 
{| IHEERO | LINKLIB 
| IHEERP |  LINKLIB | 
| IHEERR {| 2,3 
| IHEERT |  LINKLIB | 
| IHEESM |  LINKLIB | 
| IHEEXL | 24,26 
| IHEEXS | 23,25 | 
| IHEEXW | 25 l 
| IHEEXZ | 26 | 
| IHEHTL | 24,26 | 
| IHEHTS | 23,25 
| IHEIBF | 30,31,32 
{| IHEINT | 34 | | 
| IHEIOA | 27,28,29,30,31,32 
{| IHEIOB | 27,28,29 | 
| IHEIOC | 1 r 
| IHEIOD | 29,32 r 
| IHEIOF | 27,28,29,30,31,32 
| IHEION |{ 33 | 
| IHEIOP | 27,28,29,30,31,32 
| IHEIOX | 29,32 
| IHEITB |  LINKLIB | 
| IHEITC |  LINKLIB 
| IHEITD | # LINKLIB | 
{| IHEITE | LINKLIB | 
| IHEITF | LINKLIB | 
| IHEITG | £LINKLIB 
| IHEITH | # LINKLIB | 
| IHEITS | #£\LINKLIB 
{| IHEITK |  LINKLIB | 
| IHEITL |  LINKLIB | 
| IHEITP | LINKLIB | 
| IHEJXI | 18,20 
| IHEJXS | 17,18,19,20 | 
| IHEKCA j 11,13 | 
| IHEKCB | 12 | 
| IHEKCD j| 10 | 
| IHELDI | 28,31 
| <IHELDO | 28,31 | 
| IHELNL {| 24,26 | 
| IHELNS | 23,25 | 
| IHELNW | 25 | 
| IHELNZ {| 26 
{| IHELSP | 5 | 
| IHEMAI | 1 
| IHEMPU | 22 | 
| IHEMPV | 22 
| IHEMSI j{ 1 
| IHEMST j 1 
| IHEMSW | 1 | 
| IHEMXB | 21 i 
| IHEMXD | 21 
| IHEMXL | 212 | 
| IBEMXS | 21 | 
{| IHEMZU | 22 | 
L 
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Name 
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IHEMZV 
IHEMZW 
IHEMZ2Z 
IHEM9 1 
IHENL1 
IHENL2 
IHEOCL 
IHEOCT 
IHEOPN 
IHEOPO 
IHEOPP 
IHEOPQ 
IHEOPZ 
IHEOSD 
IHEOSE 
IHEOSI 
IHEOSS 
IHEOST 
IHEOSW 
IHEPDF 
IHEPDL 
IHEPDS 
IHEPDW 
IHEPDX 
IHEPDZ 
IHEPRT 
IHEPSF 
IHEPSL 
IHEPSS 
IHEPSW 
IHEPSX 
IHEPSZ 
IHEPTT 
IHERES 
IHESAP 
IHESHL 
IHESHS 
IHESIZ 
IHESMF 
IHESMG 
IHESMH 
IHESMX 
IHESNL 
IHESNS 
IHESNW 
IHESNZ 
IHESPR 
IHESQL 
IBESQS 
IHESQW 
IHESQZ 
IHESRC 
IHESRD 
IHESRT 
IHESSF 
IHESSG 
IHESSH 
IHESSX 
IHESTA 
IHESTG 
IHESTP 
IHESTR 
IHESUB 
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LINKLIB 
LINKLIB 
LINKLIB 
LINKLIB 
LINKLIB 
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1 

3 

2,3 
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18 

18 

18 

20 

20 

20 
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17 

17 

17 

19 

19 

19 

2 

1 
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24,26 
23,25 
2,3 

18 
18,20 
18,20 
20 
24,26 
23,25 
25 

26 
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24,26 
23,25 
25 

26 
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17,19 
19 
LINKLIB 
16 

16 

5 
LINKLIB 
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| Module i | 
| Name | Selected Group | 
p—---—-----—-}-—----------------------- —-{ 
| IHETCV | 2 [ 
| IHETEA | 2 { 
| IHETER | 2 | 
| IHETEV | 2 | 
| IHETEX | LINKLIB | 
| IHETHL | 24,26 ; 
| IHETHS | 23,25 | 
| IHETNL | 24,26 | 
| IHETNS | 23,25 i 
| IHETNW. | 25 | 
| IHETNZ | 26 | 
] IHETOM | LINKLIB | 
| IHETPB ( 2 [ 
| IHETPR | 2 | 
| IHETSA { 2 { 
| IHETSE | 2 | 
| IHETSS { 2 [ 
{ IHETSW | 36 | 
| IHEUPA | 8 [ 
| IHEUPB | 8,11 | 
| IHEVCA |. 8 | 
| IHEVCS | 8 | 
| IHEVFA | 6,8,11 | 
| IHEVFSB | 6,8,11 | 
| IHEVFC | 6 { 
| IHEVFD | 6,8,11 | 
| IHEVFE. { 6 | 
| IHEVKB | 11 | 
| IHEVKC | 12 | 
| IHEVKF | 11 | 
i IHEVKG | 12 | 
| IHEVPA | 6,8,11 [ 
| IHEVPB | 6,8,11 | 
| IHEVPC | 6,8,11 | 
] IHEVPD | 6,8,11 { 
| IHEVPE | 6,8,11 | 
i IHEVPF | 6,8,11 | 
| IHEVPG | 10 ( 
J IHEVPH | 9 | 
| IHEVOQA | 13 | 
| IHEVQB | 13 | 
| IHEVOQC | 13 | 
{ IHEVSA | 9 | 
| IHEVSB | 9,10 | 
[ IHEVSC | 10 i 
| IHEVSD | 9,10 | 
| ITHEVSE | 10 | 
| IHEVSF | 9,10 | 
| IHEVTB | 6 | 
| IHEXIB | 21 | 
| IHEXIC [ 21 ( 
| IHEXIL | 21 | 
| IHEXIS | 21 | 
{ IHEXIU | 22 ] 
J IHEXIV | 22 | 
| IHEXIW | 22 | 
| IHEXIZ | 22 | 
| IHEXXL | 21 { 
i IHEXXS | 21 { 
| IHEXXW | 22 | 
| IHEXXZ | 22 | 
| IHEYGF | 17,18 | 
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| 

| Name Selected Group 
pr--------—- } -- -------- = ------—------ 
| IHEYGL | 17, 18 

| IHEYGS | 17, 18 

| IHEYGW | 17,18 

| IHEYGX | 19, 20 

| IHEYGZ | 19,20 

| IHEZZA | LINKLIB 

| IHEZZB | LINKLIB 

| IHEZZC | #£LINKLIB 

| LHEZZF | LINKLIB 

betes Be oe eee J 
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APPENDIX C3: PL/I OBJECT PROGRAM PSEUDO-REGISTERS 





PL/I object programs require 
pseudo-registers (symbolic name format 
IHEQxxx), some Of which are defined by the 
compiled program, others by the library 
modules. During execution of a program 
register PR always points to the base of 
the PRV (see ‘Pseudo-Register Vector', 
Chapter 2). 


IHEQADC 


Pointer to a list of address constants 
for use by the I/0 routines: for 
non-multitasking the list is in IHESA, for 
multitasking in IHETSA. 


IHEQATV 


Contains the address of the task 
variable for the current task. 


IHEQCFL 


The current-file pseudo-register, 
8-bytes, word aligned. Used by STREAM I/0 
modules for implicit communication of the 
file currently being operated upon; see 
‘Current File’ in Chapter 3. 


IHEQCTS 


Contains the address of the save area 
for the control task in a multiprogramming 
environment. 


IHEQERR 


Serves as a parameter list when calling 
IHEERRB. The code associated with the ON 
condition to be raised is placed into 
IHEQERR. See ‘ON Conditions’ in Chapter 6. 


IHECEVT 


The anchor cell for the incomplete I/0 
event variables in a given task. When 
IHEQEVT contains zero, no I/O event 
variable in the task is incomplete. 


IHEQFOP 


The anchor cell of the chain linking the 
FCBs for the files opened in a given task. 
When IHEQFOP is zero, none of the files 
opened in this task are still open. See 
"File Control Block’ in Chapter 3. 


IHEOFVD 
Pointer to the Free VDA module: IHESAFD 


for non-multitasking, IHETSAF for 
multitasking. 


IHEQINV 


Contains the invocation count, and is 
updated by a library module each time a DSA 
is obtained. 


IHEQLCA 


Pointer to the current generation of the 
library communication area; see ‘Library 
Workspace’ in Chapters 2 and 4. 


IHEQOLPR 
Length of the pseudo-register vector. 
IHEOLSA 


Pointer to the first save area in LWS, 
which serves two purposes: (1) the save 
area provided by the error-handling 
routines for an on-unit, and (2) an area 
where initial task information is saved 
(PICA, program mask, etc.). See Chapter 4. 


IHEQLWO, IHEQLW1, IHEOLW2, IHEQLW3, IHEQLW4 


Pointers to the various levels of 
library workspace ; see ‘Library Workspace‘ 
in Chapters 2 and 4. 


IHEOLWE 


Pointer to the save area and workspace 
used by the error-handling routines when 
calling other library routines (not an 
on-unit). 


IHEQLWF 


Pointer to the reserved area attached to 
the current LWS. Used for optimization in 
storage management. See ‘Object-time 
Optimization’ in Chapter 4. 


IHEQORTC 


Contains the return code used in the 
normal termination of a PL/I program. 
Chapter 4.) 


IHEQSAR 


Contains an environment count used by 
the display modification module (IHESAR) 
when on-units and entry parameter 
procedures are used in prologues and 
epilogues. 


(See 
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IHEQSFC 


Pointer to free-core within first block 
of storage obtained by the task 
initialization library module (IHESA); see 
Chapter 4. 


IHEQSLA 


Pointer to the latest element in the DSA 
chain allocated by the storage management 


routines. The area may be a DSA or a VDA. 
See Chapter 4. 
IHEQSPR 


The file register for SYSPRINT, the name 
being standardized to allow usage of the 
same FCB for both the source program and 
the library modules. See ‘Standard Files‘, 
and ‘File Addressing Technique‘ in Chapter 
3. 


IHEOTCA 


Used only in multitasking. 
address of the tasks TCA. 


IHEQTIC 


Contains the task invocation count, 
which is used in multitasking in the 
freeing of controlled storage. 


IHEQTT1 through IHEQTTS 


Contains the pseudo entry points for the 
transfer vector tables held in the 
partition when the Shared Library feature 
is enabled. 


Contains the 


NOTE: The Shared Library feature, involving 
the pseudo-registers above, must have the 
common section of the PRV formatted in the 
following sequence: 
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(cont.) IHEQINV 


IHEQTT1 
TT2 LCA 
TT3 LSA 
TTS LWO 
TT5 LWi 
TV1 LW2 
TV2 LW3 
TV3 LW4 
TV4 LWE 
TVS LWF 
LPR RTC 
ADC SAR 
ATV SFC 
CFL SLA 
CTS SPR 
ERR TIC 
EVT VDA 
FOP XLV 
FVD TCA 
IHEQ* through IHE 5 


Contains the pseudo entry points for the 
transfer vector tables in resident main 
storage when the Shared Library feature is 
enabled. | 


IHEQVDA 


Pointer to the Get VDA module: in 
non-multitasking set(in IHESAP) to IHESADF; 
in multitasking, set (in IHETSAM) to 
IHETSAW. 


IHEQXLV 


The anchor cell for the exclusive blocks 
created in a given task. When IHEQXLV 
contains zero, the task has no exclusive 
blocks. 


IHELIB 
Operands: None 
Result: 


Definitions of LWS pseudo-registers. 

Lengths of save areas in LWS. 

Format of the library communication area. 

Definitions of save area offsets. 

Definitions of standard register 
assignments. 


IHEEVT 
Operands: None 
Result: 


Definitions of the event variable and its 
flags. 


IHEPRV 
Operands: 


A three-character code denoting the last 
three letters of a pseudo-register name 
(default: LCA) 

A code denoting a general register 
(default: WR) 

A keyword parameter OP=XX, where XX is an 
RX instruction (default: L) 


Result: 


The RX operation is performed on the 
pseudo-register. This macro is 
generally used to store the contents of 
a pseudo-register in a general 
register. 


IHESDR 
Operands: 
A three-character code denoting a 
workspace level (default: LWO) 


A code denoting a general register other 
than register DR (default: WR) 
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Result: 


The address of the required workspace 
level is put into register DR. 


IHEXLV 


Operands: None 
Result: 


Definition of exclusive block and its 
flags. 


IHEZAP 
Operands: None 
Result: 


Definitions of I/O pseudo-registers. 

Definitions of the file control block and 
its flag bytes. 

Definition of the declare control block. 

Definitions of various I/O address 
constants, parameters, operations and 
options. 

Definitions of the I/O control block and 
its flag bytes. | 

Definitions of the I/O event variable and 
its flags. 


LHEZZZ 


Operands: DUMP/none 
Result: 

If the operand is omitted, or is not 
DUMP, a full DSECT is generated. If 
the operand is DUMP, only the parameter 
list for IHEZZC is defined as a DSECT. 


Used only by IHEDUM, IHEZZC, IHEZZF. 
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APPENDIX E: PL/I LIBRARY INTERNAL ERROR CODES AND MESSAGES 


Among the errors that occur during program 
execution are errors that are covered by 
PL/I-defined conditions. If one of these 
occurs, an appropriate error code is passed 
to IHEERR in pseudo-register IHEQERR. This 
code is a 4-digit hexadecimal number. The 
two high-order digits denote the PL/I 
condition (Figure 49); the others denote 
the errors associated with that condition. 


ee a 
| Code | Condition | 
}-~-~-----—----- }---—---—-----------------| 
| 10 | STRINGRANGE 
| 18 | OVERFLOW l 
| 20 | SIZE | 
| 28 | FIXEDOVERFLOW | 
| 30 | SUBSCRIPTRANGE | 
| 38 | CHECK (label) | 
| 40 | CONVERSION | 
| 48 |} CHECK (variable) | 
| 50 | CONDITION(identifier) | 
| 58 | FINISH / | 
60 | ERROR | 
| 68 | ZERODIVIDE | 
| 70 |} UNDERFLOW | 
{ 78 | AREA | 
| 88 | NAME | 
| 90 | RECORD | 
| 98 | TRANSMIT | 
AO {| I/70 SIZE | 
A8 | KEY | 
| BO | ENDPAGE { 
| B8 | ENDFILE | 
| co | I/0 CONVERSION 
| c8 | UNDEFINEDFILE | 
a a ee 
Figure 49. Internal Codes for ON Condition 
Entries 


If system action is required, an error 
message will be printed. The messages 
relating to the errors for the PL/I 
conditions are given here. 


Error code Message 


1000 STRINGRANGE 

1800 OVERFLOW 

2000 SIZE 

2800 FIXEDOVERFLOW 

3000 SUBSCRI PTRANGE 

4000 CONVERSION 

4001 CONVERSION ERROR IN F-FORMAT 
INPUT 


4002 


4003 


4004 


4005 


4006 


4007 


4008 


4009 


5000 
5800 
6000 
6800 
7000 
7800 
7801 


7802 


8800 
9000 
9001 


9002 


9003 


9004 
9800 
9801 


CONVERSION ERROR IN E-FORMAT 
INPUT 


CONVERSION ERROR IN B-FORMAT 
INPUT 


ERROR IN CONVERSION FROM 
CHARACTER STRING TO ARITHMETIC 


ERROR IN CONVERSION FROM 
CHARACTER STRING TO BIT STRING 


ERROR IN CONVERSION FROM 
CHARACTER STRING TO PICTURED 
CHARACTER STRING 


CONVERSION ERROR IN P-FORMAT 
INPUT (DECIMAL) 


CONVERSION ERROR IN P-FORMAT 
INPUT (CHARACTER) 


CONVERSION ERROR IN P-FORMAT 
INPUT (STERLING) 


CONDITION 
FINISH 

ERROR 
ZERODIVIDE 
UNDERF LOW 
AREA SIGNALED 


AREA CONDITION RAISED IN 
ASSIGNMENT STATEMENT 


AREA CONDITION RAISED IN 
ALLOCATE STATEMENT 


UNRECOGNIZABLE DATA NAME 
RECORD CONDITION SIGNALED 


RECORD VARIABLE SMALLER THAN 
RECORD SIZE 


RECORD VARIABLE LARGER THAN 
RECORD SIZE 


ATTEMPT TO WRITE ZERO LENGTH 
RECORD 


ZERO LENGTH RECORD READ 
TRANSMIT CONDITION SIGNALED 


PERMANENT OUTPUT ERROR 
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9802 
A800 
A801 
A802 


A803. 


A804 
A805 
A806 


A807 


B800 
c800 


c801 
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PERMANENT INPUT ERROR 

KEY CONDITION SIGNALED 
KEYED RECORD NOT FOUND 
ATTEMPT TO ADD DUPLICATE KEY 
KEY SEQUENCE ERROR 

KEY CONVERSION ERROR 

KEY SPECIFICATION ERROR 


KEYED RELATIVE RECORD/TRACK 
OUTSIDE DATA SET LIMIT 


NO SPACE AVAILABLE TO ADD 
KEYED RECORD 


END OF FILE ENCOUNTERED 


UNDEFINEDFILE CONDITION 
SIGNALED 


FILE ATTRIBUTE CONFLICT AT 
OPEN 


C802 
C803 
C804 
C805 


C806 
C807 


C808 
c809 


C80A 


C80B 


FILE TYPE NOT SUPPORTED 
BLOCKSIZE NOT SPECIFIED 
CANNOT BE OPENED (NO DD CARD) 


ERROR INITIALIZING REGIONAL 
DATA SET 


CONFLICTING ATTRIBUTE AND 
ENVIRONMENT PARAMETERS 


CONFLICTING ENVIRONMENT AND/OR 
DD PARAMETERS 


KEY LENGTH NOT SPECIFIED 


INCORRECT BLOCKSIZE AND/OR 
LOGICAL RECORD SIZE 


LINESIZE GT IMPLEMENTATION 
DEFINED MAXIMUM LENGTH 


CONFLICTING ATTRIBUTE AND DD 
PARAMETERS 


The dump index provided by the subroutines 
IHE2ZZA, IHEZZB, and IHEZZC contains 
information about: 

SYSPRINT buffers 


Files currently open 


Current file 
Save areas 
On-units, interrupts and other details 


This information is output to a file called 
PL1DUMP. 


SYSPRINT Buffers 





The contents of each buffer are given, in 
EBCDIC. If U-format records are used, the 
contents of the intermediate buffer used by 
the library are also printed. 


Files Currently Open 


File name 
A(DCLCB) 
_ACFCB) 
A(DCB) 


File-register offset in PRV 


Current File 


I/O Files: File name 
A(DCLCB) 
A(FCB) 
A(DCB) 

STRING Files: A(SDV) 
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Save Areas 





A trace-back through the save-area chain 
provides the following addresses: 


A(All save areas, including the 
library save areas) 
A(Current LCA) 


A(PRV VDA) 


A(VDA for LWS2) 


Other Information 


If a CALL was made: A(CALL) 
A(Procedure) or 
A(Entry point of 
library module) 


If a BEGIN block was entered: A(Entry 
point) 


If a program interrupt occurs: A(Interrupt) 


If an on-unit was entered: Type of on-unit. 
If this on-unit is the error on-unit and 
was entered as a result of system 
action, the condition causing the system 
action is given. 


If IHEDMA occurs in the trace-back: The 
names of the modules used in the 
conversion are given. 


The statement number (if it exists) is 
given. 


The following program illustrates the 
use of the dump index: 
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TDUMP: PROC OPTIONS (MAIN); 


1 TDUMP: PROC OPTIONS(MAIN); 

2 DCL A CHAR(4Y)INIT('ABCD* ); 

3 DCL IHESARC ENTRY(FIXED BINARY(31)):; 

4 ON ERROR CALL IHEDUMP; 

6 ON CONV CALL CONVPROC; 

8 CALL IHESARC(20); 

9 PUT LIST (‘THIS IS THE FIRST LINE‘); 
10 PUT SKIP LIST('THIS IS THE SECOND 

LINE'); 

11 OPEN FILE(XYZ) OUTPUT; 
12 BEGIN; 
13 X=A;3 /* CONV ERROR */ 
14 END ; 
15 CONVPROC : PROC; 
16 DCL Y (- 32768 :-32768, -32768:-32768) CHAR(1); 
17 Z=Y (32767,32767) ; /* ADDRESSING ERROR #/ 
18 END TDUMP; — 


The addressing error only occurs if this program is the only one being executed. 


The dump index produced for this program is: 


* * * PL/I F-COMPILER 5TH VERSION * IHEDUMP * * # 


* * * SYSPRINT BUFFERS 
BUFFER 01 


HE FIRST LINE * U YA 3 R IHEOPNA O O 
BUFFER 02 


IHE804I ADDRESSING INTERRUPT IN STATEMENT 00017 AT OFFSET +000B4 
FROM ENTRY POINT CONVPROC 


*##* FILES CURRENTLY OPEN 


XYZ DCLCB OOA488 FCB O3EB40 DCB O3EB70 PR OFFSET 01C 
SYSPRINT DCLCB OOA4CO FCB O3EBDO DCB 03ECOO PR OFFSET 020 


*** CHAIN BACK THROUGH SAVE AREAS 


QO3F9BO DSA FOR ERR ON-UNIT CALLS IHEDUMP FROM OOA1FA (STMT 5) 


O3DF10 SECONDARY LIBRARY WORKSPACE 


O3DF20 SAVE AREA FOR LIBRARY CALLS OOA19C FROM OOCA3E LCA AT 03E3) 
03F690 SAVE AREA FOR LIBRARY CALLS 00A522 FROM OOCAO4 LCA AT 03F730 
O3F4C8 SAVE AREA FOR LIBRARY INTERRUPT AT OOAF86 LCA AT 03F730 
O3F8D8 DSA FOR PROC CONVPROC CALLS OOAEFO FROM 00A318 (STMT 17) 
0O3F828 DSA FOR CONV ON-UNIT CALLS 00A264 FROM OOA25E (STMT 7) 


03F338 SECONDARY LIBRARY WORKSPACE 
O3F348 SAVE AREA FOR LIBRARY CALLS 00A200 FROM OOCA3E LCA AT 03F730 


03F018 SAVE AREA FOR LIBRARY CALLS 00A522 FROM OOCAOG LCA AT O3FOB8 
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“O3EDBE 
03FE50 
03F290 
03F1B0 
03EC60 
O3FFB4 


SAVE AREA FOR LIBRARY CALLS 00C728 


FROM OOBS9CA LCA AT O3FOB8 
SAVE AREA FOR LIBRARY CALLS 00B8D0O FROM OOAFO6 LCA AT O3FOB8 
DSA FOR BEGIN CALLS OQOAEFO FROM O00A186 (STMT 13) 
DSA FOR PROC TDUMP ENTERS BEGIN AT 00A138 


PRV ~ PSEUDO REGISTERS START AT O03EC68 


EXTERNAL SA CALLS 00A020 


*#* END OF OUTPUT 


When V~format records are used, the first nine data characters of one of the SYSPRINT 
buffers may be blanked out. 


If there had been a current file, this would have appeared after the section on ‘Files 
Currently Opened’. 
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APPENDIX 


The following list comprises all the 
library modules provided for Version 5 of 
the PL/I (F) Compiler. As each module is 
aligned on a doubleword boundary in main 
storage, the length of each module given 
here has been rounded up to a multiple of 
eight. Some of the modules are not 
required by Version 5, but are included for 
compatibility with previous versions; 
numbers in parentheses after the names of 
these modules indicate the versions that do 
use them. The modules marked * reside in 
the link library (SYS1.LINKLIB); all other 
modules are in SYS1.PLiILIB. 


Module Length 
IHEABN 12 
IHEABU 224 
IHEABV 544 
IHEABW 128 
IHEABZ 128 
IHEADD 216 
IHEADV 96 
IHEAPD 360 
IHEATL 480 
IHEATS 368 
IHEATW 288 
IHEATZ 288 
IHEBEG 128 
IHEBSA 296 
IHEBSC 272 
IHEBSD 192 
IHEBSF 480 
IHEBSI 296 
IHEBSK 472 
IHEBSM 384 
IHEBSN 192 
IHEBSO 312 
IHEBSS 240 
IHEBST 584 
IHEBSV 408 
IHECFA 160 
IHECFB 584 
IHECFC 88 
IHECKP 184 
* IHECLS (1,2,3) 992 
* IHECLT 1368 
IHECNT 72 
IHECSC 200 
IHECSI 168 
IHECSK 320 
IHECSM 280 
IHECSS 224 
IHECST 304 
. JHECSV 198 
* IHECTT 1800 
IHEDBN 360 
IHEDCN 496 
IHEDDI 1264 
IHEDDJ aug 
IHEDDO 648 
IHEDDP 640 
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: LENGTHS AND LOCATIONS OF MODULES 


Module 


IHEDDT 
IHEDIA 
IHEDIB 
IHEDID 
IHEDIE 
IHEDIL 
IHEDIM 
IHEDMA 
I HEDNB 
I HEDNC 
IBEDOA 
I HEDOB 
IHEDOD 
I HEDOE 
I BEDOM 
IBEDSP 
I HEDUM 
IHEDVU 
I HEDVV 
IHEDZW 
IBEDZZ 
I HEEFL 
IHEEFS 
IHEERD 
IHEERE 
IHEERI 
IHEERN 
I HEERO 
IHEERP 
IHEERR 
IHEERS 
IHEERT 
IHEESM 
IHEESS 
IHEEXL 
IHEEXS 
I HEEXW 
IHEEXZ 
IHEHTL 
IHEHTS 
IHEIBT 
IHEIGT 
IHEINT 
IHEIOA 
IHEIOB 
IHEIOC 
IHEIOD 
IHEIOE 
IHEIOF 
IHEIOG 
IHEIOH 
IHEIOJ 
IHEION 
IHEIOP 
IHEIOX 
IBEITB 
IBEITC 
IHEITD 
IHEITE 
IHEITF 


(1,2) 


(1) 


(2) 


(1,2,3,4%) 


(1, 2,3) 


(1,2,3,4) 


(2) 
(2,3) 


Length 


760 
784 
280 
448 
456 
48 
328 
248 
2648 
648 
520 
328 
296 
224 
584 
648 
420 
488 
576 
104 
104 
688 
516 
720 
1704 
896 
4096 
856 
1272 
1824 
848 
712 
1776 
1960 
456 
248 
136 
136 
264 
176 
576 
1344 
440 
360 
480 
288 
672 
176 
736 
1108 
200 
1992 
248 
496 
336 
3784 
2640 
2280 
1760 
1856 
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Module 


IHEITG 
IHEITH 
IHEITJS 
IHEITK 
IHEITL 
IHEITM 
IHEITN 
IHEITO 
IHEITP 
IHEJXI 
IHEJXS 
IHEKCA 
IHEKCB 
IHEKCD 
IHELDI 
IHELDO 
IHELNL 
ITHELNS 
IHELNW 
ITHELNZ 
IHELSP 
IHELTT 
IHELTV 
IHEM91 
IHEMAT 
ITHEMPU 
IHEMPV 
ITHEMST 
IHEMST 
IHEMSW 
IHEMXB 
IHEMXD 
IHEMXL 
IHEMXS 
IHEMZU 
IHEMZV 
ITHEMZW 
ITHEMZZ 
IHENL1 
THENL2 
IHEOCL 
IHEOCT 
IHEOPN 
IHEOPO 
IHEOPP 
IHEOPQ 
IHEOPZ 
IHEOSD 
IHEOSE 
IHEOSI 
IHEOSS 
IHEOST 
IHEOSW 
IHEPDF 
IHEPDL 
IHEPDS 
IHEPDW 
IHEPDX 
IHEPDZ 
IHEPRT 
IHEPSF 
IHEPSL 
IHEPSS 
IHEPSW 
IHEPSX 
LHEPSZ 


Length 


1168 
2616 
2656 
736 
536 
2720 
2400 
‘2590 
936 
320 
1048 
1560 
1464 
240 
2112 
1048 
344 
264 
216 
224 
1064 


Varying 
Varying 


344 
8 
312 
288 
32 
32 
136 
152 
120 
96 
96 
344 
672 
64 
64 
280 
192 
1352 
2200 
984. 
1992 
2008 
1368 
992 
216 
80 
72 
56 
88 
1064 
144 
88 
88 
120 
288 
120 
672 
176 
72 
72 
96 
272 
96 


Module 


IHEPTT 
I HERES 
IHESAP 
IHESHL 
IHESHS 
IHESIZ 
IHESMF 
IHESMG 
I HESMH 
IHESMX 
IHESNL 
IHESNS 
IHESNW 
I HESNZ 
IHESOL 
IHESQS 
IHESOW 
IHESQZ 
IHESPR 
IHESRC 
IHESRD 


IHESRT | 


IHESSF 
IHESSG 
IHESSH 
IHESSX 
IHESTA 
IHESTG 
IHESTP 
IHESTR 
IHESUB 
IHETAB 
IHETCV 
IHETEA 
IHETER 
IHETEV 
IHETEX 
IHETHL 
IHETHS 
IHETNL 
IHETNS 
IHETNW 
IHETNZ 
IHETOM 
IHETPB 
IHETPR 
IHETSA 
IHETSE 
IHETSS 
IHETSW 
I HEUPA 
IHEUPB 
IHEVCA 
IHEVCS 
IHEVFA 
IHEVFB 
IHEVFC 
IHEVFD 
IHEVFE 
I HEVKB 
IHEVKC 
I HEVKF 
I HEVKG 
IHEVPA 
IHEVPB 
IHEVPC 


Length 


792 
104 
2488 
240 
168 
16 
136 
128 
128 
240 
408 
320 
312 
360 
160 
168 
280 
296 
32 
344 
128 
1360 
184 
104 
108 
232 
1128 
1384 
1440 
1592 
16 
16 
216 
248 
272 
256 
1468 
248 
200 
320 
256 
176 
176 
512 


272 
5720 
88 


1520 
232 
232 
272 
480 
232 
240 

40 
104 
32 
78a 
720 

1624 

1248 
352 
&24 
496 


+2 & & 


Module 


IHEVPD 
IHEVPE 
IHEVPF 
IHEVPG 
IHEVPH 
IHEVQA 
IHEVQB 
IHEVQC 
IHEVSA 
IHEVSB 
IHEVSC 
IHEVSD 
IHEVSE 
IHEVSF 
IHEVTB 
IHEXIB 
IHEXID 
IHEXIL 
IHEXIS 
IHEXIU 
IHEXIV 
IHEXIW 
IHEXIZ 
IHEXXL 
IHEXXS 
IHEXXW 
IHEXXZ 
IHEYGF 
IHEYGL 
IHEYGS 
IHEYGW 
IHEYGX 
IHEYGZ 
IHEZZA 
IHEZ2ZB 
IHEZZC 
IHEZZF 


(3) 
(3) 
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APPENDIX H: COMPI LER-GENERATED CONTROL BLOCKS 





This appendix describes all the compiler-generated control blocks used by the PL/I 
Library except the DCLCB and the OCB, which are described in Appendix I (Input/Output 
Control Blocks). All offsets are given in hexadecimal form. 
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ARRAY DOPE VECTOR (ADV) 


0 23 7 8 15 16 31 

SERRE, mS SS, a a a ce ara a | 
| Btof | | Virtual origin ] 
~---4----~1---~ +--+ -- -- + - +--+ +--+ +--+ J 
| Multiplier, | 
|-~---------------------------------------- { 
| ° | 
| : | 
| ° [ 
}----~----------------=------------------- 4 
| Multiplier, i 
}--------------~---- ~-------------------4 
| Upper bound, | Lower bound, | 
}------------------- }--------------------- 

| : | ° | 
| : | ° | 
| ° | bs [ 
}------------------- }--------------------- { 
| Upper boundy | Lower bound, | 
el era teeta eee oe Oooh tS eae td 
Figure 50. Format of the Array Dope Vector 


(ADV) 


This control block contains information 
required in the derivation of elemental 
addresses within an array data aggregate. 
The ADV is used for three functions within 
the library: 


1. Given an array, to step through the 
array in row-major order. 


2. Given the subscript values of an array 
element, to determine the element 
address. 


3. Given an element address, to determine 
its subscript values. 


Within PL/I implementation, arrays are 
stored in row-major order, upward in 
storage. The elements of an array are 
normally in contiguous storage; if the 
array is a member of a structure, its 
elements may be discontiguous. Such 
discontiguity, however, is transparent to 
algorithms which employ an array dope 
vector. 


The ADV contains (2n + 1) 32-bit words, 
where n is the number of dimensions of the 
array. The number of dimensions in the 
array is not described within the ADV, but 
is passed to the library as an additional 
argument. 


Definitions of ADV fields: 


BtOf (= Bit offset): For an array of bit 
strings with the UNALIGNED attribute, 
this is the bit offset from the byte 
address of the virtual origin. 


Virtual origin: The byte address of the 
array element whose subscript values 
are all zero, i.e. ,X(0,...,0);this 
element need not be an actual member of 
the array, in which case the virtual 
origin will address a location in 
storage outside the actual bounds of 
the array. 


Multiplier: These are fullword binary 
integers which, in the standard ADV 
algorithm, effect dimensional 
incrementation or decrementation to 
locate an element. Bit multipliers are 
used for fixed-length bit string 
arrays; byte multipliers are used for 
everything else. 


Upper Bound: Halfword binary integer, 
specifying the maximum value permitted 
for a subscript in the ith dimension. 
This value may be negative. 


Lower Bound: Halfword binary integer, 
specifying the minimum value permitted 
for a subscript in the ith dimension. 
The value may be.negative. 


ADV Algorithm: Given subscript values for 
an n-dimensional array, the address of 
any element is computed as: 


n 
Address = origin + )) Si*M, 
i=1 


where S; = value of the ith subscript 
M; = value of the ith multiplier 


For an array of bit strings with the 
UNALIGNED attribute, the origin is a 
bit address formed by concatenating the 
virual origin and the bit offset. For 
all other arrays, the origin is the 
virtual origin. 
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at al TC a a Ee ee ET Ce 


DATA ELEMENT DESCRIPTOR (DED) 


r oe ee Qe ap a a eae aD wa oe En OP ae EE er Get eee ee eer a ee ae Ee Ge GED ED EE GR De EE GE Ge Gee Ss a EE GSD SE ae ie a eae | 


| | | Bytes | 
| | pay a a eee an era 
| Data type| Representation | 1 | 2 | 3 | 4&4 | 5 | 6 and onwards | 
}--—-------}-----------—--- f----- }-----f -----} ----- f= f == 
| | Fixed-point | | | | | | | 
| {| Floating-point |Flags| p | q | - | o- | - | 
jArithmetic] Packed decimal | | | | { | | 
| }-~----------—--- $-----}-----}-----+ —---}----- }------—-------4 
| | Numeric field j|Flags| p | q | w | 1 {| Picture specn | 
}----------}--------—------- }----- }----- 4 -----} -----f ----- f+ - = === - 

| Unpictured |Flags| - | - | - | o- 4 = { 
| String }-—-- -----——-------4---—-—— 4-----1----- 4¢----—1-—~~-——1-——-—- —-------= 4 

| Pictured | Flags | 1 | Picture specification | 
as eM a ee ee A eS a geen ce ee J 


Figure 51. Format of the Data Element Descriptor (DED) 


| Code | Bit | 
| ace a. Ga, a acini, aa ran 5 a a 
| | 0 1 1 | 2 |} 3 { 4 | 5 ee | 
}---~--4+--—--------}} —----}---------}---------}-—---—-- +- -----— —}-------}--------+4 
;=0 | } * |Unaligned| Fixed {| Picture| Bit | + | 0 | 
t--—-- {05 }-----}---------}--------- $-------- ~-—--—--- $-------}-------- { 

| String i | | | No | | | 
j=1 | } * | Aligned | Varying | Picture| Character] * | 0 | 
}------4~--—------- |---| --------}--------- }-------- }- ----- -- = f------- f= == 
| | | Non- { | Numeric| | | | 
{=O | 12 { * | sterling] Short | field | Decimal | Fixed | Real | 
p------j] Arithmetic}—----4——----~----4---—--~---4}----—----4-—---- ---—- 4 -~ - +--+ 4 ----- 
j=1 | | * | Sterling| Long | Coded | Binary | Float | Complex| 
bei eee eek elie oe ee a ee ee hs iets ie ead 


* These bits are used by the compiler, but, when a DED is passed to a library 
module, they are always set to zero. 


NOTE: the hexadecimal ‘10° superimposed on the DED Flag byte indicates the presence of a 
halfword fixed point binary variable. Bit 3 is set to 1 and bit 6 is set to 0. 


Figure 52. Format of the DED Flag Byte 


Data element descriptors (DEDs) contain For numeric fields, q is the resultant 


information derived from explicit or scale factor derived from the apparent 
implicit declarations of variables of type precision as specified in the picture, 
arithmetic and string. There are four DED i.e., the number of digit positions after 
formats; they are shown in Figure 51. a V picture item as modified by an F 


(scale factor) item. 
Definitions of DED fields: 





For fixed decimal pictures, any explicit 


Flags: An eight-bit encoded form of scaling of the form F(tI) is combined 
declared information (Figure 52). Those with the implied scale, as described 
flags which are specified as zero must be above, and reflected in the DED. The 
set to zero. F(tI) is then no longer required and is 


removed from the picture. 
p byte: p is the declared or default 
precision of the data item. w byte: w specifies the number of storage 
units allocated for a numeric field. 
g byte: q is the declared or default scale 


factor of the data item, in excess-128 1 byte(s): 1 specifies the number of bytes 
notation (i.e., if the implied fractional allocated for the picture associated with 
point is between the last and the a numeric field. If the data item is 
next-to-last digit, q will have the value string, 1 occupies two bytes; if 

129). arithmetic, one byte. 
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Picture specification: This field 
contains the picture declared for the 
data item. If the data item is string, 
the picture may occupy 1 through 32,767 
bytes; if arithmetic, 1 through 255 
bytes. If the original picture 
specification contained replication 
factors, it will have been expanded in 
full... 
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DOPE VECTOR DESCRIPTOR (DVD) 


This provides a key for scanning the 2. 
Standard array, string and structure dope 
vectors. It consists of one entry for each 
Major structure, minor structure and base 
element in the original declaration. Each 

entry consists of one word and can have one 

of two formats: 


1. Structures: 


0 1 2 7 8 15 
SS eo ee ee ee 
[Fi] F2| L | N | 
Pood eee ae eh ee ee eee eee 
16 31 
re ee ee ee 1 
| Offset | 
Spe eee ee ape me nen ati OOP ee nn Eee | 
F1 = 0 Structure 
F2 = 0 
L = Level of structure 
N = Dimensionality, including 
inherited dimensions 
Offset = Offset of containing 


structure from start of 
DVD 
- 1 for a major structure 
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Base element: 


0 1 2 78 9 10 15 
Ge ee to eee 
[FI|F2| L |FS|F6] N | 
a Me ce ae re artes oa a SEEN a apenas RE eet RS J 
16 17 18 23 24 31 

ieee Se: Grier mieten er decay Geant Camille rere eared 
JF3|F4| A | {| | OD | 
Eas Rey ae eee eee epee a Sn CRA any eed ae ee eee | 
Fi = 1 Base element 
F2 = 0 Not end of structure 

= 4 End of structure 
L = Level of element 
F5 = 1 Area variable 

= 0 Not area variable 
F6 = 1 Event variable 

= 0 Not event variable 
N = Dimensionality 
F3 = 0 £=Not an aligned bit string 

= 1 Aligned bit string 
FU = 0 Not a varying string 

= 1 Varying string 
A = Alignment in bits (0 to 63) 
D = Length, if not a string, in 


bits 

= 0 if a string, in which case 
the length is in the dope 
vector 
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FORMAT ELEMENT DESCRIPTOR (FED) 


This control block contains information x 
derived from a format element within a 

format list specification for edit-directed 

I/O. There are five forms of the FED: 


1. Format item E: 


1 2 3 4 


Ss S=—-7-—--T = 

i w f{dlts| 

L__.—--~-L. 1... J Gs 
w = width of data field in characters 


dad = number of digits following decimal 


point . 

Ss = number of significant digits to be 
placed in data field (ignored for 5. 
input) 


2. Format item Fs: 


1 2 3 4 


ere a ee 
| w Ifdadlipl 


SGP ip = awe aan oes Seen 


wand da: as for E format 


p = scale factor in excess-128 
notation 


Format items A, B, X: 


| wf 


Gis Scie ceed 


w= as for E format 


Format item P: 


There are two forms of the FED for the 
P format items, these being identical 
to the DEDs for numeric fields and 
pictured character strings. 


Printing format items PAGE,SKIP, LINE, 
COLUMN : 


The FEDs for SKIP, LINE and COLUMN are 
halfword binary integers. PAGE does 
not have an FED. 
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LIBRARY COMMUNICATION AREA (LCA) 


Se aa, cma aa a a a a | 
|Symbolic|Length | [ 
| name | (bytes) | Function | 
}--------}------- }------------------------------------------------- 

0 | WBR1 | 4 | 2nd XCTL address for communication in arithmetic| 
| | {| conversion package. 

4 | WBRZ | 4 | 3rd XCTL address for communication in arithmetic| 
{ | | conversion package. | 

8 | WRCD | 8 | A(Target),A(DED): Implicit parameters for final | 
| | | conversion in arithmetic scheme. Stored by | 
| | | arithmetic director. | 

10 | WFED | 4 | A(Source FED): Implicit parameter for F or E | 
{ | | format input conversion. | 

14 | WSCF | 4 | Scale factor for library decimal intermediate | 
| ; | form. | 

18 | WSDV | 8 | Input/output field dope vector. | 

20 | WINT | 9 | Library intermediate form storage area. | 

29 | WSWA | 1 | Eight 1-bit switches: Intermodular | 
| | | communication. [ 

2A | WSWE | 1 | Eight 1-bit switches: General purpose switches. | 

2B {| wswce | 1 | Eight 1-bit switches: Not used across calls. | 
2C | WOFD | 8 | Dope vector for ONSOURCE or ONKEY built-in | 
{ | | functions. | 

34 | WOCH | y | A(Error character): ONCHAR built-in function. | 

38 | WFCS | 150 | Character string (in required format) used by | 
i | | list-directed and data-directed output. | 

CE | WCFD | 4 | Library intermediate FED: String/arithmetic | 
| | | conversion. | 

D2 | WFDT | & | A(Target FED): Implicit parameter for F or E | 
| | | format output conversion. | 

D6 | WODF | 8 | SDV for DATAFIELD in error. | 

DE | WCNV | 8 | Library GO TO control block. | 

E6 | WFIL | 4 | A(DCLCB) for ONFILE. | 

EA | WOKY | 8 | SDV(Null string); requested when ONKEY built-in | 
| | | function used out of context. | 

F2 | WEVT | 4 | ASCevent variable). | 

F6 | WREA 4 | Return address for AREA on-unit. | 
Eee eee Oy! Weer meer enna: eer EN NN FOR eal Cote Oa ONTO Sapo rp REN SNE tems enc ene en en oa n ES E Oe Fe one J 

Alternative entries: 
eRe saad Nn a ee ee ere eee ee, ee 

38 | WFC1 | 40 | Workspace for interleaved array indexer. | 

60 | WONC | 40 | Error code; storage area for contents of | 
| | | floating-point registers in error-handling ] 
| | | subroutines. | 
Aiseietcrer cia: 2 paper Lcntuncewn nan mene oeee ee a mimaread 
Ge a ee ee et a ee eg ne ee ee ee ne eee 1 

38 | WCNP | 4 | Implicit parameter: A(Constant descriptor). | 

3C | WCN1 | 8 | A(Start of constant), A(End of constant). | 

44 | WCN2 = | 8 | A(Start of constant), A(End of constant). | 
iwesetese ea a eee ssa eee ee eee are ete alas PSE pee ee Meee aA aon J 


Figure 53. Library Communication Area (LCA) 


The library communication area (LCA) is part of library workspace 
(LWS), the format of which is given in Figure 54. The use of LWS and 
LCA is described in ‘Communication Conventions’ in Chapter 2. 
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LIBRARY WORKSPACE (LWS) 


0 7 8 31 
IHEQLSA----—--- > pon nn ann nn 7 
0 | Flags | Length | 


}-------- 1-----~------------------- : 
4 | Chain-back address | 


woe wee - He  - -- - - - - - - -- - - - - ~~ - - -f 


8 | Chain-forward address | 


Cc | | 
| Register save area | 
| | 
------~~~~-—-~+------~-~--------~----4 

48 | (8 bytes unused) | 
IHEQLWO---—--- >}-----------—-----+--+-+-----+----------4 
50 | | 

| 

| Workspace level 0 | 

| 

| 

ITHEQLW 1----—~—~-> } ---—---------------- ---- - ----------- 4 
ES | | 

| 

| Workspace level 1 | 

| l 

| | 

IHEQLW2---—--- > p}--------------+-------------—------- § 
180 | | 

| | 

| Workspace level 2 | 

| | 

| | 
IHEQLW3--~-~--~>}----~-----------------+-------------4 
218 | | 

| | 

| Workspace level 3 | 

| | 

| | 

IHEQLW4--———- >} ----+-——---—----- ---. +--+ ~~~ ---~~4 

BO | 
| | 
| Workspace level 4 | 
| | 
| 

IHEQLWE-~-----> }----—----------+~------~-—-----~---j 
348 | | 

| | 

| Workspace level E | 

| | 

| | 

IHEQLCA--~—-- > }--~------—---------+-+---------------+ 4 
3E0 | | 

| | 

| 

| Library communication area (LCA) | 

[ | 

| 

IHEQLWF---—~-- S lite Sete melee eee eee ween J 


Figure 54. Standard Format of Library Workspace (LWS) 
The use of Library Workspace (LWS) is described in Chapter 2. 


The format of the LCA is given in Figure 53 and that of the SSA 
in Figure 55. 
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STANDARD SAVE AREA (SSA) 


offset General Register Standard Save Area 
Symbolic Symbolic Usage 
Value Name Number Name 0 78 es 
ee : - [Flags | °° 
8 OFDR 33 oi. tna OO 
3 - | Chain-forwara address 
Cc OFLR 14 LRRY | 
10 OFBR 15 aap ee 
= ER 0 RO | asco 
1e OFRA 1 ae yo 
OFRB 2 RB i eee eee. 
aS ; no|0| ~~~ contents of register SSS 
= * rm ot a 
OFRE 5 RE of Sm ge a 
as OFRF 6 RF eee gee 
oe ee 7 Ref "gr 
a se 8 Ro ecieoe cr ase 
oe Ores 9 RI | cela 
Se nn ences or eee 
40 OFWR 11 Kaif  .:.°.° 7 ee 
= OFFR 12 Ba esetneeecteec ace 
Figure 55. Format of the Standard Save Area (SSA) 


Flags: One-byte code, employed by PL/I 
housekeeping procedures to specify the 
nature of the storage area in which the 


SSA resides. (See Figure 56.) 


Length: Three-byte binary integer 


~Chain-forward Address: 
acquired by a called module. 


module, 
supported within the library. 


Address of the SSA 


field is not set for any PL/I Library 
Since intermodule trace is not 


specifying the total length of the 
storage area in which the SSA resides; 
used by PL/I housekeeping to free 
Gynamic storage areas. (See ‘PL/I 
Object Program Management’.) When 
OPT=01.Default is used, bit 1 of these 
three bytes is used as a flag. 


Chain-back Address: Address of the SSA 
originally provided for a module that 
now calls another module. 


Return address of the calling module: 
Contents of register LR on entry to the 
called module, set by the calling 
module to the address of the point of 
return. All PL/I Library modules 
return using register LR. 


Entry Point of the called module: Contents 
of register BR on entry to the called 
module. 
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RO to PR: Contents of the specified 
registers on entry to the called 
module. PL/I Library modules save all 
registers LR through WR in order to 
meet the requirements of a GO TO 
Statement in an on-unit. (See Chapter 
4.) The register PR field is set by 
the subroutine in IHESA that 
initializes the main procedure; it 
remains unchanged throughout the task. 


Meaning | 
| Bit }------—---.-~---_-~,,--------—--------- 
| | = 0 | a | 
}---}---------------—--1—------—--------- 
; oO | Always = 1 | 


| 1 |No statement num- |Statement number | 
| {ber field in DSA |field in DSA | 
--—4——-—-—--- ~~ = ——-~ | -- +--+ ~~ 
| 2 |No dummy ON field |STRINGRANGE field | 
| |}|for STRINGRANGE |created as for | 
| | | Jother ON conditions 


~--}---------------—-- } -----------------4 


| 3 | Procedure DSA |Begin block DSA | 
~--}-~----—---------—-}—---------—------4 
| 4 |No dummy ON field | SUBSCRIPTRANGE | 
| |for SUBSCRIPTRANGE|field created as | 
| | | for other ON con- | 
i | | ditions | 
| 5S |Non-recursive DSA, |Recursive DSA, | 
| |without display jwith display up- | 
| 


{ jupdate field |date field 
naff nn 
| 6 JNo ON fields {ON fields | 
~-—}-~---——-—-- ~~~ 4 - +--+ = 
| 7 |No dummy ON field |SIZE field created| 
| |\for SIZE jas for other ON | 
| | conditions | 
Oe eee Dh ea wel ee, J 


Figure 56. Format of the SSA Flag Byte 
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STRING ARRAY DOPE VECTOR (SADV) 


0 15 16 31 
Dave eng ea pete oO me eee ng POR pO Ee ey OMAR Saag ore Ey 1 
| | 
| | 
| | 
ADV | 
| | 
| 
| | 
ee eo ee { 





| Maximum length | Current length/0O | 


ee eet aan eer een: en meee ner an eet eee See 
Figure 57. Format of the Primary String 


Array Dope Vector (SADV) 


This control block contains information 
required to derive, directly or indirectly 
(through a secondary array of SDV entries), 
the address of elemental strings. The SADV 
is identical to the basic ADV, with the 
addition of a fullword which describes the 
string length. 


Fixed-length strings require only a 
primary dope vector. The two length fields 


are set to the same value, which is the 
declared length of the strings. 


VARYING strings require, in addition to 
the primary dope vector, a secondary dope 
vector. This consists of SDV entries for 
each elemental string within the array. 
The secondary dope vector is addressed via 
the primary dope vector by the standard ADV 
algorithm; having located the relevant SDV 
the actual string data is directly 
addressable. The maximum-length field 
appended to the ADV is set to the declared 
maximum length of each array element. The 
current-length field is set to zero. 


The multipliers of the ADV for a 
fixed-length string apply to the actual 
string data. Those of the ADV for a 
variable-length string apply to the 
secondary dope vector of SDV entries. 
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STRING DOPE VECTOR (SDV) 


0 23 7 8 15 16 31 


ea ee eS GP Gs Ss rar a aca em el ieee ae iran aa aR are | 
| 


BtOf | ; Byte address of string | 


| Maximum length | Current length { 
ee re an ene eee Be ete eee eed 
Figure 58. Format of the String Dope 
Vector (SDV) 


A string dope vector (SDV) is an 8-byte 
word-aligned block that specifies storage 
requirements for string data. 


Definition of SDV fields: 


BtOf (Bit offset): If the string is a bit 
string, positions 0 to 2 of the SDV 
specify the offset of the first bit of 
the string within the addressed byte. 
The bit offset is only applicable to 
bit strings which form part of a data 
aggregate, and then only if that 
aggregate has the UNALIGNED attribute. 


Byte address of string: For both character 
and bit strings, this three-byte field 


specifies the address of the initial 
byte of the string. 


Maximum length: Halfword binary integer 
which specifies the number of storage 
units allocated for the string; byte 
count if character string, bit count if 
bit string. This value does not vary 
for a particular generation of its 
associated string. 


Current length: Halfword binary integer 
which specifies the number of storage 
units, within the maximum length, 
currently occupied by the string; only 
applicable to strings with the VARYING 
attribute. 


The two length fields exist to 
accommodate strings with the VARYING 
attribute; in the instance of a 
fixed-length string, the two fields contain 
identical values. Both fields may contain 
a maximum value of 32,767. 
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STRUCTURE DOPE VECTOR 


4 


This control block contains information which the base elements would have if they 
required to derive, directly or indirectly, were not part of a structure, in the order 
the address of all elements of the in which the elements appear in the 
structure. structure. 


The format of a structure dope vector is 


determined as follows. The dimensions The following structure would result in 
which have been applied to the major a dope vector of the form shown below in 
structure or to minor structures are Figure 58.1. 
inherited by the contained structure base 
elements; undimensioned non-string base 1A, 2B(10), 3C(10) CHAR(6), 
elements are assigned a dope vector 3D BIT(10) VARYING, 
consisting only of a single-word address 2E, 3F FLOAT(S), 
field. The structure dope vector is then 3G(10) FIXED, 
derived by concatenating the dope vectors . 3H CHAR(3);3 

0 31 

aaa aaa Se a ant 


i C's Virtual origin { 


}--—----- —--—+----------—------------ 








7 1 
| : 
r Multiplier, | | | 
}--—------—---------—--—-------------—--4 | | 
r Multiplier, { | 
~-~--—--—-—_-----,-----—----—--—------{ | | 
| ‘Upper bound, { Lower bound, | | | 
-~—--—-——--—--—---}-----------—------4 | 
| Upper bound, i Lower bound, | | B's j 
}------------------- }-----------------—--]___ > Dope | 
| Maximum length | Current length | | Vector i 
}----------—---------4-------------------} | | 
| D's Virtual origin | | | 
}-----—-----------—--------—--------4 | 
| Multiplier | | | <A‘s 
-------~--—-~------ +7 ----—- + --—---------- | > Dope 
| Upper bound | Lower bound | { {| Vector 
~----—--——--——-—---}---~-----—----------{ | | 
{ Maximum length | 0 | 4 | 
}--—---—--------—---1----_----_--___--—_- | 
| F*s Address { 1 { 
}---------—-—----—------------------------{ | | 
| G‘s Virtual origin | | | 
p--—~ ~~~ - =f | 
| Multiplier | {| E°s | 
a nn a yf > | 
| Upper bound | Lower bound | | Vector | 
a a ee sa a a Berge | i 
| H's Address | | | 
}--~------———-- —---,----—-------—----—-4 | | 
{| Maximum length | Current length | | | 
beste aA Re ea ane) (eerie eam RR Ce een ee ERR REN J J 





eFigure 58.1 Format of the Structure Dope Vector (sDV) 
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0 7 8 15 16 31 
‘cas er Pe Pe ee 
I 0 | Chain-forward address | 
~--------}---------—--------------------4 
{ Length | l 
wonaaean- | 
| | 
| Identifier | 
| | 
}---------y--------------~--------------- { 
i D | A(DED) | 
eee pene Seen _ ea 
| Flags | Field A | 
(Sesser ra tar as apo re cereccreeccoe| 
| Field B | | | 
Ges ee ee eo eed 
Figure 59. Format of the Symbol Table 
(SYMTAB) 


The symbol table consists of one or more 
entries which define the attributes, 
identifier, and storage location of 
variables which appear in the data list for 
data-directed I/O. Each SYMTAB entry 
contains the address of the next entry or a 
stopper. 


Definition of SYMTAB fields: 


Chain-forward address: The address of the 
next entry in the symbol table; all 
symbols (identifiers) known within a 
given block are chained together. The 
last entry in the chain is signaled by 
a zero chain-forward address. (The 
symbol table of a contained block must 
include the symbol table of the 
containing block; hence the 
chain-forward address of the last entry 
for variables declared in a contained 
block is that of the first entry in the 
symbol table of the containing block.) 


Length: Number of characters comprising the 
identifier. Maximum length is 255 
characters. 


Identifier: The name declared for a 
variable. If the variable is known by 
a qualified name, the identifier 
includes separating periods. 


D (= Dimensionality): The number of 
dimensions declared for an array 
variable; D = 0 for scalar variables. 


A(DED): Address of the data element 
descriptor associated with the 
variable. 


Flags: 
Bit 
0 (Reserved) 
1 = 1 ON CHECK for the variable 
2 = 1 =ON CHECK for label variable 
3 (Reserved) 
4 (Reserved) 
Bits 
567 
000 Variable is STATIC 
001 Non-structured AUTOMATIC or 
CONTROLLED 
010 Structured AUTOMATIC or 
CONTROLLED 
Field A: 


If STATIC: Address of data item or its 
dope vector. 


If AUTOMATIC (non-structured): Offset of 
data item or its dope vector 
within DSA. (See note.) 


If AUTOMATIC (structured): Offset of dope 
vector for data item (within a 
structure dope vector), 
relative to origin of DSA. 
(See note.) 


If CONTROLLED (non-structured): offset to 
data item or its dope vector. 


If CONTROLLED(structured): As for 
AUTOMATIC (structured), but 
offset is relative to origin 
of structure dope vector. 


Field B: 


If STATIC: Not used. 


If AUTOMATIC: Offset of display within 
PRV. 


If CONTROLLED: Offset of the anchor word 
(pseudo-register) of the 
controlled variable. 


Note: See Chapter 4 for description of 


storage class implementation and for 
definition of DSA. 
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APPENDIX I: INPUT/OUTPUT CONTROL BLOCKS 





This appendix gives the formats of the control blocks used by the PL/I Library I/0 
interface modules, including those blocks generated by the compiler. The functions of 


the blocks and the way in which they are used by the library are described in Chapter 3. 
In the diagrams, all offsets are in hexadecimal. 


The appendix includes an example of the chaining of I/O control blocks. 
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DECLARE CONTROL BLOCK (DCLCB) 


~ 
= o© 940 oOo ££ So 


ash 


Figure 60. 


DPRO: 


DCLA: 


0 7 8 15 16 23 24 31 


DPRO | DCLA | 


}---------~--------}-------------------4 


l DBLK DLRL 


eit tee Sema ai fe ot 


| DCLD | DBNO | DCLB | oDcLcC | 


}---------4---—--_ f------------------4 


| DXAL |NCP Value|Reserved | 


|--—---------------4--------1------—-4 


| a (Reserved) | 


| ----------------—--------------—--—--4 


| | (Reserved) | 


a-----—-7-------=-------------------=4 


{| DFLN | 


}-------——-J 


DFIL 


é 


| 
| 
| 
| 
| 
| 
| 
J 


Coe a= Ginny Cem Git GERD Gis Go dist aaa dame qfge CEE ae Gib Gees eS ahs ey i GE Ge Ge ee ee ee ee CE a SE GE Ge 


Format of the Declare Control 
Block (DCLCB) 


Halfword binary integer (set by the 
linkage editor) specifying the offset, 
within the pseudo-register vector 
(PRV), of the pseudo-register 
associated with the declared file. 


Four four-bit codes specifying 
the file type, organization, access and 
mode: 


Byte 1 
Type 

Q001 xxxx STREAM 
0010 xxxx RECORD 

| Organization 
xxxx 0000 CONSECUTIVE 
xxxx 0001 INDEXED 
xxxx 0010 REGIONAL (1) 
xxxx 0011 REGIONAL (2) 
xxxx 0100 REGIONAL (3) 
xxxx 0101 TELEPROCESSING 


(Stream-oriented I/O is supported only 
for data sets of CONSECUTIVE 
organization. ) 


DBLK: 


DLRL: 


Byte 2 

Access 
0001 xxxx SEQUENTIAL 
0010 xxxx DIRECT 


(These are used for record-oriented I/0 
only. ) 


Mode 
xxxx 0001 INPUT 
xxxx 0010 OUTPUT 
xxxx 0100 UPDATE 
xxxx 1000 BACKWARDS 


(Stream-oriented I/O uses INPUT and 
OUTPUT only.) 


Halfword binary integer specifying 
the length, in bytes, of the blocks 
within the data set: 


F-format records: block length 
specified for data set (constant 
for all blocks except possibly the 
last one). 


U-, V-, VS- or VBS-format records: 
maximum length of any block in 
data set. 


TP; maximum message length 


Halfword binary integer specifying 
the length, in bytes, of the records 
within the data set. Two or more 
records may be grouped (blocked) to 
form one physical block. 


F-format records: record length 
specified for data set (constant 
for all records). 


V-, VS- or VBS-format records: maximum 
length of any record in the data 
set. 


U-format records: this specification is 
not permitted; the block size 
defines the record length. 
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DCLD: 


DBNO: 


DCLB: 
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One byte containing 


ENVIRONMENT options: 


Bit 


sO UNS WN a © 


Option 


LEAVE 
COBOL file 
CTLASA 
CTL360 
INDEXAREA 
NOWRITE 
REWIND 
GENKEY 


One-byte binary integer specifying 


the number of buffers to be allocated 
to the file when it is opened, as 
specified by the BUFFERS option. 


es) 
pute 
ct 


SAU ES WH = © | 


One byte containing attribute 
codes: 


Attribute 


KEYED 
EXCLUSIVE 
BUFFERED 
UNBUFFERED 
TRANSIENT 
(Reserved) 
(Reserved) 
(Reserved) 


DCLC: Eight-bit code which specifies the 
format of records within the data set: 


Bits Code Format 
0 and 1 01 V 
0 and 1 10 F 
0 and 1 11 U 
2 - (Reserved) 
3 1 Blocked 
4 1 VS/VBS 
5 1 PRINT/G 
6 1 R 
7 - (Reserved) 


DXAL: 


Halfword binary integer specifying 


the count in the INDEXAREA area 


environment option. 


DFLN: 


One-byte binary integer specifying 


the length (minus one) in bytes of the 
file name in the following field. 


DFIL: Character string, 
long, specifying the 
If there is no TITLE 
statement, the first 


up to 31 bytes 
name of the file. 
option in the OPEN 
eight characters 


of this name are used as the name of 
the DD statement associated with the 


file during program execution. 


(The 


compiler wiil have padded the name with 
blanks to extend it to at least eight 


characters in length. 


) 


EVENT VARIABLE 


0 7 8 15 16 31 

0 | EVF1 | EVEC | 

secre ——------ —~- +--+ -- ---- --------{4 

4 | EVF2 | EVIO | 

}------ 4--~-~-----~------------—------ 

8 | EVCF { 

}-~----—--~-----—-----—--------------| 

e' EVCB | 

|------—---------—-y----------------—-| 

10 | EVST | Reserved | 

}--—---—-----~-~---4-------------------] 

14 | EVFF | 

}----- --------------------------------- { 

18 | EVFB | 

}--—~--~-------------------------------4 

1c | EVPR | 

ee eee ee eee eee ae ee J 
Figure 61. Format of the Event Variable 


In a multitasking environment, event 
variables are placed in two chains: 


1. The file chain, which is anchored in 
the TEVT field of the FCB and includes 
all active event variables related to 
a file and for which there is no 
corresponding IOCB. This chain 
enables all associated event variables 
that are not being waited on to be set 
inactive, complete, and abnormal when 
a file is closed. 


2. The task chain, which is anchored in 
the pseudo-register IHEQEVT, and 
includes all active I/O event 
variables associated with the task. 
This chain facilitates the setting of 
those event variables that are not 
being waited on inactive, complete, 
and abnormal on termination of the 
task. 


An example of the chaining of event 
variables is given at the end of this 
appendix. 


EVF 1: 


EVEC: 


EVF2. 


EVIO: 


EVCF: 


EVCB: 


EVST: 


EVFF: 


EVFB: 


EVPR: 


8-bit code containing implementation 
flags: 

Flags Code Name 
Active event variable 1000 0000 EMAC 
I/O associations 0100 0000 EMIO 
No WAIT required 0010 0000 EMNW 
FCB address contained 

in the first word 0001 0000 EMFC 
This event variable | 

is to be checked 0000 1000 EMCH 
DISPLAY event variable 0000 0100 ENDS 
IGNORE option with 

this event 0000 0010 EMIG 


Contains the address of the DECB 
associated with the event, or the 
address of the FCB when no IOCB was 
obtained, e.g., when READ IGNORE (0) 
is executed. 


PL/I ECB flag byte: 





Flags Code Name 

Wait 1000 0000 EMWB 

Complete 0100 0000 EMCP 
Not used. 


Event variable chain-forward pointer 
(task). 


Event variable chain-back pointer 
(task). 


Status field: 

Normal status value: All zeros. 
Abnormal status value: Low-order bit 
is 1, remainder is zero (unless 
set otherwise by STATUS 

pseudo-variable). 


Event variable chain-forward pointer 
(file). 


Event variable chain-back pointer 
(file). 


Address of the PRV of the task in 
which the associated I/O event was 
initiated. 
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EXCLUSIVE BLOCK 


0 7 8 15 16 31 
Er pare ey ee ae te ee an 

0 | XCFF | 
}------—---------—----—-----------4 

4 | XCBF | 
}---~--—-------------—-----------| 

8 | XCFT | 
}----------~------~--—----------4 

c | XCBT | 
}----------—-----—--------------- { 

10 | XPRV | 
aera ae | ERRRRIEOGITS GneEDIcUSUae Race | 

14 | XFL1 | (Reserved) | XSTC | 
[--—--- ~--------1--------------4 

18 | | 
| XQNM | 

| 
20 | XLRN | XKYI/XREG | 
}------1---------—-----—--------- 

24 | | 
| | 

| XKYR | 

| | 

| 

| | 

| | 

(jeeesse eee eee eee eee J 
Figure 62. Format of Exclusive Block 


Exclusive blocks are placed in two 
chains: 


A 


1. The task chain, which is anchored in 


the pseudo-register IHEQXLV, and 


enables all records locked in a task 


to be unlocked when the task is 
terminated. 


2. The file chain, which is anchored in 


the TXLV field of the FCB, and 
facilitates the freeing of all 


exclusive blocks related to the file 
when it is closed, and facilitates a 
check on whether a record is already 


locked. 


An example of the chaining of exclusive 


blocks is given at the end of this 
appendix. 


XCFF: 


XCBF : 


XCFT: 
XCBT 


XPRV : 


XFL1: 


XSTC: 


XONM: 


XRNM: 


Chain-forward pointer (file). 


Chain-back pointer (file). 


Chain-forward pointer (task). 
Chain-back pointer (task). 


Address of the PRV for the task in 
which the exclusive block was 
created. 


Flags: XLOK: Code 1000 0000 indicates 
that the record associated with the 
exclusive block is locked owing to a 
READ operation or an incomplete 
REWRITE or DELETE operation. 


Lock statement count: the number of 
incomplete I/O operations that 
currently refer to the exclusive 
block. 


Eight-byte qname used in the ENQ and 
DEQ macro instructions. The first 
word contains the address of the FCB, 
right-aligned, and the second 
contains zero. 


The rname used in the ENQ and DEQ 
macro instructions: 


XLRN: One byte containing the length 
of the rname. 


XKYI/XREG: 
XKY¥YI: INDEXED files (unblocked 
records): Key of record | 
being locked. 
INDEXED files (blocked 
records): A(FCB). 
REGIONAL files: Region 
number of the record 
being locked. 


XREG : 


XKYR: REGIONAL(2) and (3) files: 
recorded key of the record 


being locked. 


The 
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FILE CONTROL BLOCK (FCB) 


10 
14 
18 
1¢ 
20 
24 
28 
2c 
30 


Figure 63. 


TVAL: 


TRES: 


TFLX: 


0 7 8 15 16 23 24 31 


rf a DP SP SP SS SP 6 OP BS SS SD 6 6 SD 6 On ee 6S 6 ee Ge @ Oe 2 ee eee ne ee ee 


| TVAL | 


}----------------------—-------—------- 


( TRES | 


~-------y-------—---—-----------------4 


| FLX | TDCB | 


}-------- $-----~-------—---------------4 


| TYP | TACM l 


~-----—}---------7-—--------------—- 


{| TFLA | TFLB | TLEN 


mo f -- - — bf 


| FIO | TDCL | 


p------—-4_------—---------------------4 


TCBA | 


-}----- -------- -- =~ 


ne 
l TREM | TMAX | 


}------—---------—-1-------------------4 


l TREC | 


}------—--------------------—-------—--| 


l TCNT l 


}-------~----------y-------------------4 


| TPGZ l TLNZ 


+ T 4 
l TLNN | TFLC | TFLD | 


{| TFLE | TFOP r 


~--~----}-------—---—-----------------4 


TFLF | TTAB 


-----—-1-----~---~- -- --—- -- ~~ -~------4 


DCB 


—-—---—-7- 


A ccc ii ec dn mig emi Ne ei ml esa i rh emi dies es fe a le | 


FCB for Stream-Oriented I/0 
Word containing bits indicating 
which statements are valid for this 
file 

Reserved 


Eight-bit code specifying error and 
exceptional conditions: 





Conditions Code Name 
EOF on data set 1000 0000. TMEF 
Error on output 0100 0000 TMOE 
Error on input 0010 0000 TMIE 
Error on data field 0001 0000 MTMIT 
Do not raise 

TRANSMIT 0000 1000 TMNX 
List terminator 0000 0010 TMLC 
ENDPAGE raised 0000 0001 TMEP 


10 
14 
18 
1c 
20 
24 
28 
2c 
30 
34 
38 
3C 
40 


0 7 8 15 16 23 24 31 
ee I er ee ge ee eee 
| TVAL | 
p----~------ —--- == =~ - == -- =f 
| TRES | 
}-------- Yorn arn nnn 
| TFLX | TDCB | 
p-------— fon nn nn nnn nn nnn nnn nnn nnn 
| TTYP | TACM | 
~-------}---------y-----—------—------ 
|. TFLA | TFLB | TLEN | 
~-------}---~-- ~~ 1 -- +--+ - —-] 
| FIO | TDCL 
a+ -1L------ --- + - - --- +--+ 
| TLAB/TCBA | 
}-—-----~-------—---------------------| 
| TPKA/TSWA | 
pom nnn nn nnn nnn nn nnn nen { 
| TBBZ/TREL | 
}-------------—---------------------—- 
| TADC | 
penn - n= nn o----—- —---- —- { 
| TLRR/TAID | 
enn nan nnn nn nn pon nnn nn nnn nn 
| TLRL | TFLC | TFLD | 
-~----~7-~---- - 1-1 
| TFLE | TFOP { 
~-------}---------y----------------—-4 
| TFLF { =TFMP | (Reserved) { 
}—-------1--~.--~-- 1..---—---..----_--—--J 
TEVT 
prom nnn nnn nnn nn nen nnn nnn nnn nanan} 
| zero | 
poa— nano a nnn nnn === { 
TXLV* | 
pono nnn nnn nn nnn nn nnn n= | 
| zero* | 
pron nnn nn nnn nnn nnn nnn - === === -- =f 
| TXLZ* i 


}-—------------—------------------------ 


| 
| 
| 
DCB 
| 
| 
| 
J 


gre aan ce eee ee ee a ae 


* These fields are omitted in 


Figure 64. 


TDCB: 


TTYP: 
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non-multitasking environment: DCB 
commences at byte 38. 


FCB for Record-Oriented I/0 
Address of the DCB part of the FCB. 


Eight-bit code specifying I/O .type: 
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Type Code 





STREAM I/0 xXXX 


RECORD I/0 xXXX 
STRING I/0 XxXXX 
Temporary flags, 1000 
valid for single 0100 

I/O call only 0010 

0001 


0000 
0001 
0010 
XXXX 
XXXX 
XXXX 
XXXX 


Name 


TMDS 
TMRC 
TMST 
TMT1 
TMT2 
TMT3 
TMT4 


TACMs Address of I/O transmit module, 


which interfaces with data management 
access methods. The names of all such 
library modules are IHEIT*, where * is 


a letter identifying the module. 


TFLA: Two four-bit codes specifying the 
record format and the current file 








mode : 
Format Code 
V (variable) 0001 xxxx 
F (fixed) 0010 xxxx 
U (undefined) 0100 xxxx 
ASA control/print 
file 1xxx xXxXXx 
Mode Code 
INPUT xxxx 0001 
OUTPUT xxxx 0010 
UPDATE Xxxx 0100 
BACKWARDS xxxx 1000 


TFLB: Eight-bit code specifying the file 


attributes: 

Attribute Code 
EXCLUSIVE 1xxxX xXxXxXxX 
UNBUFFERED x1xx xxxx 
Hidden buffers xx1x xxxx 
SYSPRINT file XxxX1 xXxxx 
Hidden buffer may 

be required XxXXxX x1xx 
KEYED XXXX xx1x 
DIRECT XXXX XXXL 


TLEN: Halfword binary integer, specifying 


Name 


TMVB 
TMFX 
TMUN 


TMAS 


Name 


TMIN 
TMOP 
TMUP 
TMBK 


Name 


TMEX 
TMBU 
TMHB 
TMPT 


TMHQ 
TMKD 
TMDR 


the length, in bytes, of the FCB. 


TFIO: Eight-bit code specifying the type 


of I/O operation: 





Operation Code 
PUT 1000 0000 
GET 0100 0000 
EVENT option 

with IGNORE option 0000 0010 
COPY option 0000 0001 


Name 


TMPW 
TMGR 


TMEIL 
TMCY 


TDCL: Address of the DCLCB defining the 


file. 
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STREAM: 


RECORD : 


TCBA/TLAB: 


TCBA: Address of next available 
byte in a buffer. 


TLAB: 

Sequential: Address of last 
IOCB obtained. 

Direct: Address of first IOCB 
in chain. 

TCBA?3 

Sequential: Address of last 
record located. 


TREM/TMAX/TPKA : 


STREAM: 


RECORD: 


TREM: Number of bytes remaining 
in current record. This value 
is equal to TLNZ when the 
record is initialized for 
output. 

TMAX: Halfword binary integer 
specifying the number of bytes 
in a record: 


Input: the number of bytes 
read. 


Output: the number of bytes 
initially available. 


For V format records, this 
number includes the four-byte 
record control field; for all 
record formats, it includes the 
ASA control byte (if present). 


TPKA: Address of previous key. 
(Used for SEQUENTIAL access to 
REGIONAL data sets, LOCATE 
creation of INDEXED data sets, 
and padding key for SEQUENTIAL 
INDEXED data sets.) 

TSWA: Address of data in dummy 
buffer got at OPEN time 


TREC/TBBZ/TREL: 


STREAM: 


RECORD: 


TCNT/TADC: 


STREAM: 


TREC: Address of buffer 
workspace (paper-tape input, 
U-format output). 


TBBZ: Length of IOCB. The 
first byte contains the subpool 
number. 

TREL: Relative record count. 
(Usea only for SEQUENTIAL 
access to REGIONAL data sets.) 


TCNT: .Fullword binary integer 
specifying the number of scalar 
items transmitted during the 
most recent I/O operation (GET 
or PUT) on the file 


RECORD: TADC: Address of the adcon 


list. 


TPGZ/TLNZ/TLRR/TAID: 


STREAM: TPGZ: Halfword binary integer 


RECORD: 


specifying the maximum number 
of lines per page. This field 
is only used for PRINT files. 
A default value of 60 lines is 
assumed if: 


1. the OPEN statement that 
opens the file does not 
include the PAGESIZE 
option, or 


2. an implicit open occurs. 


TLNZ: Halfword binary integer 
specifying the maximum number 
of characters per line. A 
default line size is obtained 
from the record length 
specified in the ENVIRONMENT 
attribute if: 


1. the OPEN statement that 
opens the file does not 
include the LINESIZE 
option, or 


2- an implicit open occurs. 


If the ENVIRONMENT attribute is 
not specified, the record 
length used is that specified 
in the associated DD statement. 


If none of these specifies a 
record size, and if the file is 
a print file, a default length 
of 120 characters per line is 
assumed. 


The TLNZ value includes all 
characters available within a 
line. 


TLRR: Address of IOCB of last 
complete READ operation. This 
is required whenever the EVENT 
option is used; it provides a 
means of identifying the last 
complete READ operation when a 
REWRITE is executed. In the 
case of spanned records this 
field holds the length of the 
previously read record if the 
previous Operation was a READ 
SET. 

TAID: Address of dummy work 
area for terminal 
identification. 


TLNN/TLRL: 


STREAM: 


RECORD : 


TLNN: Halfword binary integer 


specifying the current line 


number. 


length for the file. 


TFLC: Two 4-bit codes giving: 


1. Type of device. 

2. Further file history. 
Device Code 
Paper tape 1000 0000 
Printer 0100 0000 

Previous operation 

was READ with SET 

option 0000 1000 
Attempt to close in 

wrong task 0000 0100 
OPEN or CLOSE 

in progress 0000 0010 


TFLD: 


organization of the data set associated 


TLRL: Maximum logical record 


Name 
TMPA 
TMPR 
TMPS 
TMDT 


TMOC 


Eight-bit code specifying the 


with the file: 


Organization 


CONSECUTIVE 
INDEXED 

REGIONAL (1) 
REGIONAL (2) 


REGIONAL 


(3) 


TELEPROCESSING 


TELE: 


history of the file: 


Preceding operation 


Code 


x*00° 
x*Ou® 
x°08° 
X*0OC° 
Xx*10° 
x*°14° 


Name 


TMCN 
TMIX 
TMR1 
TMR2 
TMR3 
TMTP 


Eight-bit code specifying the 


History 


a READ 


IGNORE in progress 
CLOSE in progress 
End of the extent 


Preceding operation 


Preceding operation 


reached by the 
last operation 


a REWRITE 


a LOCATE 


I/O condition on 


CLOSE 


Implicit CLOSE 


TFOP : 
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Code 


1000 
0100 
0010 
0001 
0000 
0000 


0000 
0000 


0000 
0000 
0000 
0000 
1000 
0100 


0010 
0001 


Name 


TMRP 
TMIG 
TMCL 
TMET 
TMWP 
TMLT 


TMCC 
TMCT 


Address of the prior FCB opened in 
the current task, or zero (if FCB is 
the first FCB opened). 
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TFLF: Eight-bit code specifying the 
load module code (used by IHECLS, 
IHECLT and IHECTT to specify module 
names in the DELETE macro): 


STREAM: 





Miscellaneous Code Name 


TAB table exists 0000 0001 TMTB 


RECORD: 

Module Code Code Name 
QSAM X*00* TMQS 
BDAM  xX*oage TMBD 
OQISAM X*08° TMOL 
BISAM X*OcC* TMBI 
BSAM X*10° TMBS 
BSAM load mode x*14' TMBL 
OTAM x°18° TMQT 
Tab control table 

exists X*01° TMTB 


TTAB: Address of TAB control table (PRINT 
files only). 


TFMP: RECORD I/O only. This flag is used 
by exclusive files to act as a lockout 
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flag when updating the chains of IOCBs 
and exclusive blocks. A TS loop is 
performed on this byte until it is 
freed. When the chaining operation is 
complete, the byte is set to zero. 


TEVT: Pointer to chain of active I/O event 
variables associated with the file, but 
for which there is no corresponding 
IOCB: enables the event variables to be 
set complete, inactive, and abnormal 
when the file is closed. 


TXLV: Pointer to chain of exclusive blocks 
associated with locked records of the 
file: enables locked records to be 
unlocked when the file is closed. 
(Used only in a multitasking 
environment. ) 


TXLZ: Length of exclusive block: the first 
byte contains X‘'01°( the number of the 
subpool in which storage for the block 
is allocated). 


DCB: This field, variable in length and 
format, is the data control block 
defined by data management for the 
various access methods. 


INPUT/OUTPUT CONTROL BLOCK (IOCB) 


14 
18 
1c 
20 
24 
28 
2c 
30 
34 
38 
3C 
40 
44 
48 
4c 
50 


0 7 8 15 16 31 

~-------- y-- - -- +--+ - +--+ + 5 ee = + 
| BaAcT | BPIO A 
}------—- 1__-—---------~----------------4 

| BNIO | | 
~-----—--------------------------------- | 

| BERR | BFCB | | 
}--~---—-- 1_------------------------------ { | 

| BREQ | 
}------—------------- qo7---~--------—---- { 

| BERC/BEFC/BXTC/BKYC | BRCC | LOCB 
}-~-----——---—------~-~--1-------------------- 4 foundation 

| BRVS | | 
}----------------------------------------- { | 

| : BEVN | | 
}--~----—---------------------------------{ | 

| BDF 1/BBF 1 | 
ae ee 5 Sabie iak ee ena EaR ces | 

| BDF 2/BBF2 | BDF3/ (Reserved) | | 
}-------------------- 1----------—---—----- { 

| BDF4/BBF3 | | 
}------—--~~------------------------—----4 

| | BDF5/BBF3 (contd. ) | Vv 
}-------—--------------------------------- }------------------- 
| BECB/BEXD | A A 
}--—------------ —--y--------------------4 | | 

BTYP l BLEN | BSAM BDAM/BISAM 
po --————-- = ~--- —-- L- 4 DECB DECB 

l BDCB | | | 
}------—------------------~--------------4 | | 

| BARE 1 | | 
}------—---------—------------------------ { | 

| BSTS/BLOG | V | 

p------ = - === == == === === == === === = +------ | 
BKVS/BKEY 
}------—--------------—------------------ | 

l BBLK/BEXI | Vv 
pra nnn nn nnn nnn nn nn nn nnn nnn nnn fome nnn e meen nnn 
| BDBF/BXLV | A 
|--—---—---------------------------------- 4 | 

| (Reserved) { | 
}------—--------- -------------------------| BDAM/BSAM 
j | Hidden 

| BBBF | buffer 

| | area 

| | | 

| 

| | V 
eee eee eee a eee ie elie Ghee are eee ee 


Note: (The IOCB includes the Data Event Control Block (DECB) 


for the BSAM and BDAM/BISAM Interfaces) 


Figure 65. Format of the I/O Control Block (IOCB) 


BACT: One byte containing an activity flag BPIO: Chain-back address of the previous 


(used only in direct access): I/O control block. 
BNIO: Chain-forward address of the 
Code Meaning next I/O control block. 
X'FF* In use BERR: Flag byte for record-oriented 
x'00° Free I/O situations: 
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Situation Code Name 
IOCB has been checked 0000 0001 BMCH 
I/O error exists 0000 0010 BMER 
End-of-file has 

occurred 0000 0100 BMEF 
Possible lock for 

REWRITE 0000 1000 BMPR 
Lock for 

REWRITE 0001 0000 BMNR 
IOCB for BISAM 

READ UPDATE mode 0100 0000 BMDF 
Dummy buffer acquired 1000 0000 BMDB 


BFCB: Address of the FCB for the file. 

BREQ: Request control block. Four-byte 
field specifying the request codes for 
associated operations (as passed by the 
compiled calling sequence): 


Byte 1 Operation 

x'oOo? READ 

x'our WRITE 

x'os* REWRITE 

x*0Oc* DELETE 

x'10° LOCATE 

x*°14° UNLOCK 

x'18° WAIT 

Byte 2 Option Set 1 

x*"o0OoO°* None/SET 

xX*'Ou! IGNORE 

x'o8s* INTO/ FROM 

Byte 3 Option Set 2 

x*'00* None 

X*ou? KEYTO 

x'os' NOLOCK 

Byte 4 Option Set 3 

x*20'° EVENT option 

x*'4ugor VARYING record variable 
(INTO) 

x*80° VARYING KEYTO 


BERC/BEFC/BXTC/BKYC: Error codes for 
various conditions. 


BERC: ERROR condition 
BEFC: ENDFILE condition 
BXTC: TRANSMIT condition 
BKYC: KEY condition 


(See Chapter 6 for details of these 
codes.) 


BRCC: Error code for RECORD condition. 


(See Chapter 6 for details of these 
codes.) 
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BRVS: Address of RDV or SDV for record 


variable. 


BEVN: Address of event variable; zero, if 
none exists for associated operation. 


BDF1/BBF1: 


BSAM: BDF1: Address of the user's 
record variable. 


BDAM: BBF1: Address of the user's 
record variable. 


BDF 2/BBF2 


BSAM: BDF2: Length, in bytes, of the 
user's record variable. 


BDAM: BBF2: Length, in bytes, of the 
user's record variable. 


BDF3: 


BSAM: Length, in bytes, of the KEYTO 
area. 


BDAM: (Reserved) 


BDF4/BBF3 


BSAM: BDF&: Address of the KEYTO area. 


BDAM: BBF3: Relative record or track 
number (BLKREF). 


BDF5: BSAM: Relative record number 
(REGIONAL (1)). 


BECB/BEXD: 


BECB: The data management event control 
block (ECB). 


BEXD: If BDAM is used, bytes 2 and 3 
(= BEXD) of this field contain 
the BDAM exception codes. For 
definitions of these codes, see 


IBM System/360 Operating System: 


Supervisor and Data Management 
Macro Instructions. 


BTYP: Type of I/O operation (set 
by data management macro). 


BLEN: Length, in bytes, of the records to 
be transmitted. 


BDCB: Address of the DCB. 
BARE: 


Address of the 
appended buffer. 

No hidden buffers: Address of the record 
variable. 


Hidden buffers: 


BSTS/BLOG: BEXI: If BISAM is used, one byte 
(= BEXI) contains the BISAM 


BSAM: BSTS: Address of the status exception codes. For definitions 
indicator. of these codes, see IBM 
System/360 Operating System: 
BDAM: BLOG: Address of the IOB (I/0 Supervisor and Data Management 
block; see IBM System/360 Macro Instructions. 


Operating System: System 
Programmer's Guide. 


BISAM: BLOG: Address of the logical BDBF/BXLV: 
record. 
BKVS/BKEY BSAM and BISAM: BDBF: Start of hidden 
buffer. 
BSAM: BKVS: Address of SDV for KEYTO. 
BDAM: BKEY: Address of KEY BDAM: BXLV: Address of the exclusive 
block (if any) associated with 
BBLK/BEXI : record being referenced. 


BBLK: Address of BLKREF, the relative 


record or track number (i.e., the BBBF: Start of BDAM/BISAM hidden buffer. 
address of BBF3). 


ne eae eae Se ee ee ee a ee ee [oS ae eo ne eee : 
| | SEQUENTIAL | DIRECT | 
| Siar REE aR REE 7-7 S- === === deen nme ren ren / Sea a maa a 
| | CONSECUTIVE | REGIONAL | REGIONAL | INDEXED | 
(KEYED) | | 

| | j (1) (2) (3) | (1) (2) (3) | 

}---------—--}--------- --~- f= == y= fn nny nnn fn n { 
| F-format | A |; A {| A | A | A Jf A | A f A | 
| records | B i Bt BYsBéYtycecqyjcyfc | Cc | 
| | | 8 | Da | Os | 8 [| Da | Da | Ds | 
l | | | Da [ Da | [ | | Da | 
| | | ] ] ] 16 ] 
| | | [ | | | (Note 1) | 
}---------—--}------------- f----- f-----}----- =f ----- f= ff 
| V-format | A wen) eo a | | . | 
| records | B | | | B | [ } c¢c | | 
| | D2 | [ | Ds | | | Ds | | 
| | | | D2 | | | Da | | 
}-----~-------}-------------- + ---- f-----f--- = f= ff ! 
| U-format | A eee ee ee ee 7 | 
| records | B | [ | B | | |} c | | 
| | | | | Os | | Da | | 
[ | | | | Da | | | 
}-----—-----——. Be $2 eke oes 5 eee 4 -——— | ea renee ; een [eae ae eae ene eee nee 4 
| Az: Size of IOCB foundation j|Note 1: If RKP # 0, then D, = 0.| 
| Bs: Size of BSAM DECB JI£f RKP = 0 then for blocked | 
| Cs: Size of BDAM/BISAM DECB |records: Dy, = L, and for i 
j Ds: Size of hidden buffer: Junblocked records: D, = 2L, | 
| Dz: Length of recorded key jwhere L = length of recorded | 
] Da: Length of block (record) | key. | 
i {Note 2: The data value is ob- | 
| jtained by summing the sizes | 
| |Igiven under each entry. | 
a a eo ew oe eee ee ee eee ee i etre Ps BE elt taped poe ner ve Ds ee ee Ee J 


Figure 66. Values used in Computing Size of IOCB for Various Access Methods 
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0 Ki 8 12 
nian! an ee ee Se ee a Saar acaet ata | 
| Type | 0 | Access | Mode { 
beicoowuse See eae elec bee ee 
16 20 24 28 31 
{| Flag A | Flag B | Flagc | FlagD | 
L a a GP Ge ae ee a ee oe A es la igh i tee OR ee Sb ee ee a alicia cine amen aad 
Figure 67. Format of the Open Control 
Block (OCB) 
Type STREAM 0001 
RECORD 0010 
Access SEQUENTIAL 0001 
DIRECT 0010 
Mode INPUT 0001 
OUTPUT 0010 
UPDATE 0100 
BACKWARDS 1000 
Flag A Bit: 0 KEYED 
1 EXCLUSIVE 
2 BUFFERED 
3 UNBUFFERED 
Flag B 0 TRANSIENT 
Flag C (Reserved) 
Flag D Bit: 0 (Reserved) 
1 PRINT 
2 (Reserved) 
3 (Reserved) 


CA al a en a rar ee 
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EXAMPLE OF CHAINING 


Figure 68 contains an example of the 
chaining of FCBs, IOCBS, event variables, 
and exclusive blocks in a single task. 


Files 


The task has opened two files, and the 
addresses of their FCBs (FCB1 and FCB2) are 
stored in the PRV; the FCBs are placed ina 
chain that is anchored in the 
pseudo-register IHEQFOP and uses the TFOP 
fields in the FCBs. The task also has 
access to another file that was opened ina 
higher task; the address of the FCB for 
this file (FCB3) was copied into the PRV 
when the task was attached. (Note that 
this FCB does not appear in the IHEQFOP 
chain.) A DCLCB exists for each file 
declared, but only the one corresponding to 
FCB1 is shown in Figure 68; this file is an 
exclusive file that has been opened for 
DIRECT UPDATE. 


IOCBS 





Three of the current I/O operations that 
refer to FCB1 required IOCBs. The IOCBs 
are placed in a chain anchored in the TLAB 
field of the FCB so that they can be freed 
when the file is closed. The BXLV field in 
each IOCB addresses the corresponding 
exclusive block. The EVENT option was used 
with two of the I/O operations: the BEVN 
fields in IOCBs 1 and 3 therefore point to 
the corresponding event variables. (The 
third operation originated in another 
task.) 


Event Variables 


The task has four active I/O event 
variables. These are chained from the 
pseudo-register IHEQEVT so that, on 


termination of the task, they can be set 
complete, inactive, and abnormal. (Note 
that the address in the chain-back field 
EVCB in event variable 1 is not that of 
IHEQEVT, but that of the field three words 
higher: IHEQEVT is thus in the same 
position relative to this address as EVCB 
is relative to the first byte of the event 
variable.) Event variables 1, 3, and 4 
relate to the file corresponding to FCB1, 
and must be set complete, inactive, and 
abnormal when the file is closed. 
Communication with event variables 1 and 3 
is established via the corresponding IOCBs. 
But event variable 4, which relates to an 
I/O operation for which an IOCB was not 
required, is placed in a chain anchored in 
the TEVT field of the FCB. Event variable 
2 is related to an I/O operation on another 
file in the task. 


Exclusive Blocks 


For REGIONAL files and INDEXED files with 
unblocked records, an exclusive block 
exists for each record currently locked; 
all those shown refer to the file 
corresponding to FCB1. (If the files have 
blocked records, only one exclusive block 
exists for each file in each task; it is 
created the first time a record in the file 
is locked, and is not freed until the file 
is closed.) The exclusive blocks are 
placed in a chain anchored in the TXLV 
field of the FCB so that the blocks can be 
freed when the file is closed. Only two of 
the records have been locked by this task, 
and their exclusive blocks (1 and 3) are 
placed in a chain anchored in 
pseudo-register IHEQXLV so that the records 
can be unlocked on termination of the task. 
(Note that the chain-back fields, xXCBT and 
XCBF, in exclusive block 1 point, not to 
IHEQXLV and TXLV, but to fields in the PRV 
and FCB1 that have the same positions 
relative to IHEQXLV and TXLV as the start 
of the exclusive block has relative to xXCBT 
and XCBF.) 
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FCBL 


ITHEQXLV 
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= 8 


Figure 68. 
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Example of Chaining of I/O Control Blocks 


APPENDIX J: STORAGE-MANAGEMENT CONTROL BLOCKS 


This appendix gives the formats of the control blocks used by the non-multitasking 
storage-management modules of the PL/I Library; the formats of the multitasking 
equivalents are given in Appendix K. The functions of the blocks and the way they are 
used are described in Chapter 4. In the diagrams, all offsets are in hexadecimal. 
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AREA VARIABLE 


r T 1 
0 {See Note | Length of Area Variable | 


}---------4_-----------—------------—-- 


4 | Offset of End of Extent | 
an oe ee ae ee om re ee ee er ee ew ewe ee wee 4 
8 | Offset of Largest Free Element | 
}--------------------------------------{ 
Cc See Note 


ae ques GE ee GD Ge ae Gee ene ay ame 
mam aoe came eee eee eee ae eee en oes ane 


ee ee eo ee ee 

Note: If the area variable contains a free 
list, bit 0 of the first byte is set 
to 1, and the fourth word is set to 


Figure 69. Format of Area Variable 
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DYNAMIC STORAGE AREA (DSA) 





0 7 8 31 

a ey ne 

0 {| Flags | Length | 

}--—--—--1_- -----__-- —-__---_---_---—- 

4 | Chain-back address | 

p--—— ~~~ ------ == - —-—------f 

8 | Chain-forward address | 

}--—------- —-------- —----—--——------ { 

c | | 

o | 

- | Register save area | 

- | | 

44 | | 

|---------—-----~-----------—---—-j 

4s | Current file | 

| ; 

|--—---—---- —-- --------------—------ { 

50 | Invocation count | 

| , 

58 |OPTIONAL ENTRIES: | 

- | | 

- | Display | 

- | Statement number ] 

- | ON fields . | 

| | 

| Dope vectors { 

| 

| AUTOMATIC data ] 

| Workspace | 

| Parameter lists | 

| | 

i area eee ees ee es 
Figure 70. Format of the Dynamic Storage 


Area (DSA) 


The minimum size of a non-multitasking 
DSA is X*64* bytes. 


Standard Entries 


Standard Save Areas The area starting with 
the flags and continuing up to and 
including the register save area. 
Figure 55 and associated text.) 


(See 


Current File: This field is eight bytes 
long; its use is described in ‘Current 
File’ in Chapter 3. In a multitasking 
environment, the first byte is used as the 
SYSPRINT resource counter; see ‘SYSPRINT in 
Multitasking’ in Chapter 3. 


Invocation Count: This field is eight bytes 
long and contains: 


ist word: Environment chain-back address or 
zero 


2nd words Invocation count 


aa are eee ee es ar ee ee ere 1 

Meaning | 
| Bit }-----—----—_---_--, —-------__--------} 
i | = 0 | =1 | 
}--------------------4-------------- 
| oO | Always = 1 | 





—---7---------------—--| 
| 1 |No statement num- |Statement number | 
| Jber field in DSA |field in DSA { 


~--4-----------—---—--}------------------| 


jwithout display jwith display up-_ | 
jupdate field jdate field | 
}---4-----~-----—----$ -------—--------} 


| 6 [No ON fields JON fields { 


}---4— 
7 {No dummy ON field |SIZE field created| 


| 2 {No dummy ON field |STRINGRANGE field | 
| | for STRINGRANGE |created as for | 
| | Jother ON condi- | 
—— {tions | 
}---}-----------—--—---} ----—----- —---——- 
| 3 |Procedure DSA {Begin block DSA { 
p= fan nn nnn fn nn nn 

{| 4 |No dummy ON field |SUBSCRIPTRANGE i 
| | for SUBSCRIPTRANGE|field created as_ | 
| | |for other ON con- | 
| | | ditions : 
}~--4—-----—----—-----} ----——----—-------] 
| 5 |Non-recursive DSA, |Recursive DSA, | 
{ 

| 


| 

| | for SIZE jas for other ON | 
| | | conditions | 
a a ah 
Figure 71. Format of the DSA Flag Byte 


Optional Entries 


Display: This field is eight bytes long and 
contains: 


ist word: Pseudo-register offset 


2nd word: Pseudo-register update 
If it occurs at all, the display field 
always appears at offset 58. 


Statement Numbers This field is four bytes 
long; it is described in ‘Error and 
Interrupt Handling’. If it occurs at all, 
the statement number always appears at 
offset 60; bytes 60-61 are always set to 
zero and bytes 62-63 contain the statement 
number in hexadecimal notation. If there 
is no statement number, this field can be 
used for optional DSA entries, e.g., ON 
fields. 


ON fields: Each ON field is two words long. 
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The ON fields are described in ‘ON 
Conditions’ under ‘Error and Interrupt 
Handling’. The position of the first ON 
field depends on whether there are entries 
in the display update and statement number 
fields: 


1. No display update, no statement 
number: ON fields begin at offset 58. 


2. Display update, but no statement 
number: ON fields begin at offset 60. 


3. Statement number (with or without a 


display update): ON fields begin at 
offset 64. 


230 


‘Blocks'). 


The last ON field is indicated by bit 
0 = 1 in the second word. 


Remaining Entries 


The dope vector formats are described in 
Appendix H ('Compiler-Generated Control 
The AUTOMATIC data, workspace 
and parameter lists areas are provided for 
use by the compiler. 


VARIABLE DATA AREA (VDA) | 0 7 8 31 


0] Flags | Length(= L(PRV) + L(LWS) + 8) | 
0 7 8 31 pee nn - -- 4 - - - -- ~~ + + - - + - + + + 4 
f-------- Enea aE etateeetenteneetenestentetentententeneateteet eaten 1 4 | A(External save area) | 
0| Flags | Length | }----- --- + + a oe oe = 4 
----——~-1----- ~~ --—---- -- -- - - - -- - -- 8 | | 
4 | Chain-back address [ | Pseudo-register vector (PRV) | 
}----—-----—- —- --------—-----------------4 | 
8 | | |------------------—--------------—------- 
| Data t | | 
| | | Library workspace (LWS) [ 
be ee Se eee ee ei ea | , | 
Figure 72. Format of the Variable Data bon nn nn nn nnn nn - -- - -- | 
Area (VDA) | | 
| LWF(DSA optimization area, | 
| OPT=01 only | 
| 
Ue ee a eee ee eee 
Figure 74. Format of the PRV VDA 

0 7 8 31 
‘ a See eee ee ee ee eee 
O|{ Flags | Length | 
}---------1----------------------------] 
4 | Chain-back address | 
(-~---—------------ ------------------ =} }----------------—-------------—---—-] 
| Bit | | 8 | Chain-back address { 
a - + - 7 - - - --- - | Meaning |. | (previous LWS) | 
(012344567 | | $}---------—- - ---- --- -- -- ---- ---- ——---—- 4 
}--------- +--------- }+---------------------{ i (unused) | 
| ] | | }-------------------------------------- 
}1090210 40000 | Ordinary VDA4 i 10 | | 
----------+-——------—--- --------- --~- --------| | Library workspace (LWS) | 
}/0010j 0001 | VDA obtained fora | | | 
| | | library subroutine? | ban nnn nnn nnn nnn ee |] 
~~-------}---------}---—-----------------] | | 
{00104031 01 | VDA containing a | | LWF(DSA optimization area, | 
| i | secondary LWS | { OPT=01 only) | 
~-------- ——-~---}---—--------------—--4 | | 
{10010 {1 001 | PRV VDA | L-—- -—- —— —— —$ -—-—- —- — - -  ——— — ——- — —-— - — I 

tssceee | 4------------.--------J Figure 75. Format of LWS VDA 


Figure 73. Format of the VDA Flag Byte 
14VDA obtained to hold automatic data declared with adjustable bounds or lengths. 


2VDA obtained for a library subroutine, or obtained by compiled code for a temporary data 
item. 
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APPENDIX K: MULTITASKING CONTROL BLOCKS 


This appendix describes the control blocks used by the multitasking storage-management 
modules of the PL/I Library. The way in which they are used by the library is described 
in Chapter 5. In the diagrams, all offsets are in hexadecimal. 
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CONTROL TASK STORAGE AREA 


0 pra nnn nnn nnn nan nnn nnn nnn nn nnn nny 


used by control task for 


Parameter list for IHESUB 
Parameter list for attach macro 
Parameter list for IHETEXC 


48 }|------~--~--—~—---+-—-+—-----—— —-- —— -- ~~~ --- 4 
l | WORKSPACE: 
| Works pace 
| (a) 
90 }-----~-~---~----—---—- ~~ ------—----------- 4 (b) 
(c) 
| Major Task Task Variable | 
| | 
AC }------------ ---~--—-- ---- -- ---- -------- 4 
| 
| Major Task Event Variable | 
| | 
CC }-----~-—-------+--——-+-- -- -- -- - + --- + 4 
| | ECBLIST: 256 words for a maximum of 256 
| ECBLIST | tasks. The last entry in contains 
| | X°80*° in top byte. 
WCC }----------—-—-------~ -- ~-------------=-- 
| { CTECB: the ECB posted by tasks after 
| CTECB y completion of "soft" code. 
WDO l—~—--—--—-— +--+ — — ~~ — —- — — + 


e Figure 76. Format of the Control Task Storage Area for Multitasking 
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DYNAMIC STORAGE AREA (DSA) 


0 7 8 31 
=o a a a | 

0 { Flags | Length | 
}------ —1_-----~----------------------- { 

4 | Chain-back address | 
}--------------------------------------{ 

8 | Chain-forward address | 
|-------------------------------------- { 

Cc | i 
| 
- | Register save area | 
ot | 
uy | | 
[---------------~----------------------- 1 

us | | 
| 

| Current file | 

| 
}------------~-~----------------------- { 

50 | | 
| | 

| Invocation count | 

| 
}-------------------------------------- { 

58 | | 
| Display | 

| | 
}-------y------------------------------ { 

60 | Flags | Statement number | 
}------- 4_---~~---~--------------------- { 

64 | A(Task variable chain) | 
|-------------------------------------- 

68 | Zero | 
fs i ee een es 

6C | ON fields | 
| Dope vectors | 

r AUTOMATIC data | 

| Wor kspace | 

| Parameter lists | 
ee ee toe ee eee ee eee | 


Figure 77. Format of the Dynamic Storage 
Area (DSA) for Multitasking 


The minimum size of a multitasking DSA 
is X'6C‘ bytes. 


The multitasking DSA contains two fields 
that do not appear in the non-multitasking 
DSA (Appendix J): the fullword commencing 
at byte 64 contains the address of the 
first task variable in the task-variable 
chain (if any); the following fullword is 
always set to zero. The presence of a task 
variable chain is indicated by bit 0 = 1 in 
byte 60. The Get DSA routine IHETSAD 
differs from its non-multitasking 
equivalent only in that it sets the 
doubleword commencing at byte 64 to zero. 
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EVENT VARIABLE 


0 7 8 15 16 23 24 31 
oe er a or pe ere 1 
QO | Flags | Reserved | 
ee Se eee a ee en 
y | Internal PL/I ECB | 
}------------------------------------- { 
8 | Reserved | 
a a as ea | 
Cc | Reserved | 
a qr nro ee nn ee ene 
10 | Status | Statement Number | 
p—--~—-—-~----—---~- ee eet eee eae 
14 | Reserved | 
|-------------------------------------- { 
is | Reserved | 
}-------------------------------------- { 
ic | External ECB | 
a nee eee eTENE ree nae ey Re PEND area) Cara eee rea J 


e Figure 78. Format of the Event Variable 


The task event variable is not chained. 


Flags: 
Flag Code 
Active event variable 1000 0000 
Dummy event variable obtained 
by control task 0100 0000 
Normal PL/I termination 0010 0000 
Abnormal PL/I termination 0001 0000 


Internal PL/I ECB: This is the internal 
PL/I event control block. Bit 0 is 
set to 1 when a WAIT macro instruction 
referring to this ECB is issued; bit 1 
is set to 1 when a POST macro 
instruction is issued. When a WAIT 
for a task event is specified, this 
ECB is waited on until posted by PL/I 
control task. 


Status: Normal status: set to zero. 
Abnormal status: set to 1. 


Statement Number: Number of the statement 
in which the task was attached. 


External ECB: This ECB is specified to the 
control program when the task is 
attached. When the task is detached, 
the control program posts this ECB. 
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PRV VDA 


[on em are ow ae on o~ ae a Om 6 Om 6 ee a ae 6 Oe ewe oe oe OF Om a ee Oe = a ae oe ee oe ee 


| Optional entries: 

| ON field 

| Parameter list 

| 


Figure 79. Format of PRV VDA for 
Multitasking 


A PRV VDA for multitasking is identified 
by a iin the first bit of the length field 
(bit 8 of the PRV VDA). Like its 
non-multitasking counterpart (Appendix J), 
it contains the PRV and primary LWS and is 
chained back to the external save area. It 


differs in the settings of the flag byte 


and in the presence of the following 
additional fields immediately following the 


PRV: 


ist 
2nd 
3rd 


4th 


The 
are 


word: Chain back to the DSA of the 


attaching task. 


words: Chain back to the PRV VDA of 


the attaching task. 
word: Address of its own task 
variable. 


word: Address of the parameter list 


for the called procedure; 


this word is set to zero. 


if no 
parameters are being passed, 


following fields are omitted if there 


no entries: 


ON field: When a subtask is attached, the 
entries in the ON field of the 


Parameter list: 


DSA of the attaching task are 


copied into this field. 


called procedure. 


The settinos of the flag byte are as 
follows: 
Major task x*29% 
Subtask X*2D° 
Subtask with entries 
in ON field x 2F* 
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TASK VARIABLE 


14 


18 


0 718 15 16 31 
i ee ee a ee ee 
| Flags | ACPRV VDA) | 
}-------$--------—--—-—--------------- { 
| | A(TCB) | 
}------- fowen nnn nn { 
[ | AC(SYMTAB entry) | 
[------- }--------—--------------------- 
| | A(Event variable) | 
Berg =e St ee 
| Limit priority |Dispatching | 

| priority | 
J------ Seweetebaeseel oe eee See 
| | Chain-forward address | 
pon a anna pon nnn nnn nnn nnn nnn nen == 4 
| | Chain-back address | 
Cooma ga a ta a is ee a ae eS 


Figure 80. Format of the Task Variable 


The task variable contains the task 


control information required by the PL/I 
Library. To enable subtasks to be detached 
when the attaching task is terminated, all 
task variables activated in a task are 
placed in a chain anchored in the DSA of 
the attaching task. Only the first two 
bits of the flag bytes are used: 


Bit 1: 0O = Task variable inactive (task 
not attached) 
1= Task variable active 
Bit 2: 0O = CALL with TASK variable 
specified 
1 = CALL without TASK variable 
specified 
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TASK COMMUNICATION AREA 


am a a 1 
l PECB 

8 a a eee ea seen assen eat { 
| PLIST l 
aaa aa { 
WECB 
a ca ada | 
l FLAGS | WORKS PACE l 
ee aa een, na of See ea RAL SEN oe ee J 


e Figure 81. Format of the Task 
Communication Area 


The TCA contains the POST and WAIT ECBs 
required by tasks wishing to request 
control task facilities, e.g., CALL another 
task, change priorities, etc. 


PECB: task post ECB; posts code requesting 
control task action 


PLIST: parameter list passed to control 


WECB: task wait ECB; waits until control 


task 


task has accepted request. 


FLAGS 
=] =Q 

[aoe ee ee a aaa 1 
| BIT| Message | PL/I | 
; oO | Task | Subtask | 
}---}------------------ }------------------ { 
|BIT| Task enqueuved | Not | 
} 1 | on control task | enqueued | 
}---}------------------ }------------------ { 
| BIT | Reserved | Reserved | 
| 2-6 | | 
}---}------------------}------------------4 
| BIT | Enqueued | Not | 
} 7 | on IHEOPEN | enqueued | 
eee a ee es 
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APPENDIX L: PL/I LIBRARY MODULE NAMES, MEMBER NAMES AND ALIASES 


This appendix contains a table listing the 
PL/I Library modules in alphabetical order 
along with their associated member names 
and aliases. For a description of each 
module, see Chapter 9, Module Summaries. 
In the interests of clarity, the preceding 
characters IHE, as indicated by the first 
entries, have been omitted. 


Module Name | Member Name | 


Br re en ee ee 
| Module Name H Member Name | Aliases | 
wa ------ ———- - $ -- --- -—--- -- -- } ------------- 4 
| IHEABN | IHEABNO | None | 
| ABU | ABUO | : | 
1 ABV i ABVO | % | 
| ABW | ABWO | . | 
| ABZ i ABZ0 | ™ | 
| ADD | ADDO | - | 
| ADV | ADVO | . ( 
i APD | APDA |  APDB | 
| ATL { ATLS {| ATL, | 
| | | 263 | 
| ATS | ATS1 | ATS 2, 3 | 
| | 64 | 
| ATW ' ATWN | # £ATWH i 
| ATZ { ATZN | #£ATZH | 
| BEG i BEGN | BEGA | 
| BSA ( BSAO { None | 
| BSC | BSCO | | 
| BSD | BSDO | - | 
| BSF | BSFO | ” | 
| BSI | BSIO | . | 
{ BSK i BSKK | BSKA, i 
| | |  BSKR | 
{ BSM i BSMF_ | BSMV, | 
| | |  BSM2Z | 
| BSN | BSNO | None | 
| BSO | BSOO j . | 
| BSS [ BSS2 | BSS3 { 
| BST | BSTA | None | 
| BSV | BSVA | * | 
| CFA | CFAA | M4 | 
| CFB \ CFBA_ | - | 
| CFC i CFCA | . i 
{ CKP i CKPT | : ; 
| CLT | CLTA |  CLTB i 
i CNT i CNTA | CNTB | 
i csc | cscO | None | 
| csI | CsIO | . | 
{ CSK | CSKK | CSKR | 
| CSM | CSMF_i| None | 
{ css | css2. |  css3 { 
| CST | CSTA | None | 
| CSV | CSVA | ° | 
{ CTT | CTTA | £CTTB, { 
| | | cre | 
| DBN | DBNA | ODBN | 
| DCN { DCNA | DCN, | 
| | | DCNB | 
| DDI | DDIA | DDIB | 
| DDJ i DDJIA | ODD | 
bee ae ele hee eee ee eee ed 


Aliases 


. 
| 


| 
}-~------~----}----——---—--}-—---—---—-f 
| DDO | DDOA | DDOB, 
| | | bpo, 
| | {| DDOD, 
| | | DDOE 
| DDP | DDPA ; DDPB, 
| | |  DDPC, 
| | | DDPD 
i DDI | DDTA | DDB, 
| | | {|  DprTc, 
| | | DDTD, 
{ | |  DDTE 
| DIA | DIAA | DIA, 
| { | DIAB 
; DIB { DIBA | #£ODIBB 
| DID | DIDA | None 
| DIE | DIEA | DIE 

i DIL | DILA | DILB 
| DIM | DIMA | None 
| DMA | DMAA | DMA 

\ DNB | DNBA | DNB 
DNC | DNCA | DNC 

t DOA | DOAA | DOA, 
| |  DOAB 
DOB | DOBA |  DOBB, 
| | | DOBC 
| DOD | DODA | DODB 
| DOE | DOEA | DOE 

| DOM [ DOMA | None 
| DSP | DSPA | as 

| DUM j DUMP | DUMC, 
| DUM, 
| | | DUMT 
| DVU | DVUO | None 
| DVvV | Dvvo—_ [|X * 
DZW | DZwO | : 

| DZZ | Dzz0~—si| . 

| EFL | EFLC | EFLF 
| EFS | EFSF |  EFSC 
| ERD i ERDA | None 
| ERE | EREA | . 

{ ERI | ERIA | 7 

; ERO | EROA | . 

| ERP | ERPA | > 

{ ERR | ERRA | ERRB, 
| | | ERRC, 
| | | | ERRD 
| ERT | ERTA | None 
| ESM | ESMA |  ESMB 
| EXL | EXLO | None 
| EXS | ExsO | * 

i EXW | Exwo | ° 

i EXZ | EXZ0 | i 

\ HTL | HTLO | . 

| BTS | HTSO | = 

[ IBT | IBTA | #£IBTB, 
| | IBTC, 
| | | IBTD, 
i | | IBTE 
bosses e Peete Fas Spa nN ae ee 
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r 
| Module Name | Member Name | 


INT 
IOA 


IOB 


LOC 


IOD 
LOF 
ION 
IOP 


IOX 


| 

| 

| 

{ 

| 

| 

; 

| 

| 

| 

| 

| 

| 

{ 

| 

ITB 
ITC 
| ITD 
| ITE 
ITF 
ITG 
| ITH 
ITJ 
ITK 
ITL 
ITP 
IxXI 
| JXS 
| KCA 
| KCB 
KCD 
{ 

r LDI 
| 

| 

| 

| 

| 

| 

i 

; 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

L 


LDO 
LNL 
LNS 


LNW 
LNZ 
LSP 


LTT 


LTV 
MAT 
MPU 
MPV 
MSI 
MST 
MSW 
MXB 
MXD 
MXL 
MXS 
MZU 
MZV 


GD EP CS ES ae a ED Pee 
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INTA 
IOAA 


TOBA 


IOCA 


IODG 
IOFA 
IONA 
IOPA 


IOXA 


ITBA 
ITCA 
ITDA 
ITEA 
ITFA 
ITGA 
ITHA 
ITJA 
ITKA 
ITLA 
ITPA 
JXII 
JXSTI 
KCAA 
KCBA 
KCDA 


LDIA 


aD ie GED TS GEE Qe She CEE GE cere cae 


Aliases 


~-----------}-------------} 


None 
IOAB, 
IOAC, 
IOAD 
IOBB, 
IOBC, 
IOBD, 
IOBE 
IOCB, 
rocc 
IODP 
None 
i] 
IOPB, 
IOPC 
IOXB, 
IOXC 
None 


JXIY 
JSXY 


KCB 
KCD, 
KCDB 
LDIB, 
LDIc, 
LDID 
LDOB, 
LDOC 
LNLD, 
LNLE 
LNSD, 
LNSE 
None 
a 


LSPB, 
LSPC, 
LS PD 
None 


| Module Name | Member Name | 


(> ee ee ee eee a oe a ee oe me ee oe ee oe oe eee ae oe ae EA GEES GAD ES aD EE eee GED CEES a Se CE GED GD ce! oe CREE aune = gee ees WEEE ee GEE SEED qe ane? SE es OEE GES: Ges a EE OEE qe a ee ee EE dee ae ee 


ma een Hf a 


MZW 
M2ZZ 
M91 


NL1 
NL2 


OCL 


ocT 


OPN 
OPO 
OPP 
OPQ 
OPZ 
OSD 
OSE 
ost 
OSS 
ost 
OSW 
PDF 
PDL 
PDS 
PDW 
PDX 
PDZ 
PRT 
PSF 
PSL 
PSS 
PSW 


PSX » 


PSZ 
PIT 
RES 
SAP 


SHL 
SHS 
S1Z 
SMF 
SMG 
SMH 
SMX 
SNL 


SNS 


SNW 


SNZ 


Se ee ee 
Aliases. 
| MZWO | None 
| MZzZO~— | 48 
| M91A | M91, 
| | M91iB, 
[ | M91C 
| NLiIN | LNIA, 
| | NL1L 
| NL2N | #£=.NL2A, 
| | NL2L 
| OCLA [ OCLB, 
| | oclLe, 
| | OCLD 
| OCTA |  OCTB, 
| | oct, 
| |  ocTD 
i OPNA | None 
| OPOA | “ 
| OPPA | 
| OPQA fl" 
| OPZA | - 
| OSDA { . 
| OSEA | i 
{ OSIA | . 
| OSSA | . 
i OSTA | : 
i OSWA | is 
| PDFO | . 
| PDLO | i 
| Ppso { e 
| PDWO | - 
| PDXO | = 
| PDZO | . 
{ PRTA |  PRTB 
| PSFO | None 
| PSLO | . 
i Psso_ | . 
| PSWwO | 5 
| PSx0 | ° 
{ PSZO { . 
| PTTA | #£PTTB 
REST |  RESN 
| SAPA |  SAPB, 
| | SAPC, 
| | SAPD, 
| | SADA 
| SHLS | SHLC 
SHSS |  SHSC 
| SIZE | None 
| SMFO_ | * 
| SMSC |  SMGR 
| SMHC |  SMBAR 
| SMXO | None 
| SNLK |  SNILC, 
| |  SNLS, 
| | SNLZ 
[ SNSS | SNSC, 
{ |  SNSK, 
| | SNSZ 
| SNWK |  SNNC, 
| | SNWS, 
| |  SNWZ 
| SNZK |  SNZC, 
| {|  SNZs, 
| | SNZZ 
i a a a A aa a al a as Ma beeen aaa 


c 
Module Name | Member Name | 


| Aliases i 
}----------—-- -------------}------------- 
| SPR | SPRT | None | 
| SQL | SQLO | . ; 
| SQS | sQso | . | 
| SQW | SQWO | a | 
| SQZ | SQZ0 { : | 
i SRC i SRCA |  SRCB, | 
| | [ SRCC, | 
| | SRCD, 
| | | SRCE 
| SRD | SRDA | None ( 
SRT i SRTA | SRTB, 
| | |  SRTC, 
| | | SRTD 
| SSF | SSFO | None | 
i SSG | SssGcC |  SSGR | 
| SSH { SSHC |  SSHR i 
| ssx { SSxXxO | # None | 
; STA | STAA { . | 
| STG { STGA | STGB { 
[ STP | STPA | None | 
| STR | STRA i STRB, | 
| |  STRC | 
| SUB | SUBA | None 
| TAB | TABS | . | 
TCV i TCVA |  ‘TCVB { 
| TEA | TEAA | None | 
TER | TERA | #£TER { 
| TEV | TEVA | None | 
] TEX | TEXA | #£TEXB, { 
| | | TEXC | 
| THL | THLO | None | 
{ THS i THSO | . { 
| TNL { TNLD | #=TNLR | 
| TNS i TNSD | ‘TNSR ; 
| TNW | TNWH | £TNWN | 
| TNZ | TNZH | # =TNZN ; 
; TOM | TOMA | TOMB, | 
| | |  TOMC, | 
| | | TOMD { 
| TPB | TPBA | #£None 
TRP TPRA | 7 { 
i TSA { TSAP | # £TSAA, | 
| | | TSAB, { 
| | | TSAD, 
| | | TSAO | 
| TSE | TSEA | None \ 
| TSS TSSA | . [ 
] TSW { TSWA | " 
i UPA i UPAA | UPAB | 
| UPB | UPBA |  UPBB i 
| VCA | VCAA | VCA { 
| vcs | VCcSA | VCS, | 
| | VCSB [ 
VFA [ VFAA | VFA | 
| VFB | VFBA_ | VFB | 
| VFC [ VFCA |  VFC { 
{ VFD [ VFDA |  VFD | 
{ VFE { VFEA |  VFE 
| VKB i VKBA | VKB i 
i VKC i VKCA | VKC | 
| VKF i VKFA | VKF { 
{ VKG i VKGA |  VKG { 
| VPA | VPAA | VPA | 
VPB | VPBA |  VPB j 
as ee Se ee ee ea eee 


Re re ah reg eee ee ed 
| Module Name | Member Name | Aliases | 
}---~---------}-------------}-------------4 
| VPC | VPCA | VPC 
i VPD | VPDA | VPD | 
j VPE | VPEA | VPE ] 
| VPF | VPFA |  VPF | 
| VPG ] VPGA | VPG | 
| VPH | VPHA |  # VPH | 
| VQA | VQAA | None i 
| VOB | VOBA | VOB | 
i voc | VOCA | voc | 
{ VSA VSAA | VSA | 
| VSB | VSBA | VSB | 
| vsc | VSCA | vsc | 
| vVsD | VSDA | VSD, | 
| |  VSDB | 
; VSE | VSEA | VSE, 
| | | VSEB | 
| VSF | VSFA |  4VSF | 
| VTB | VTBA | None | 
| XIB | XIBO | “i | 
| XID | XIDO | i | 
| XIL | XILO | = | 
j xIS | XISO | | 
| XIU | XI00 | i | 
| XIV | XIVO | | 
| XIwW | XIWO | . | 
| X1IZ | XIZ0 | ™ | 
| XXL | XXLO- | : { 
; Xxs | XxsoO_ | : | 
| XXW | XXwO | i ] 
{ XXZ | XxzO~— || : \ 
| YGF | YGFV | YGFS | 
{ YGL | YGLV | YGLS | 
i YGS | YGsv | YGSS i 
| YGW | YGWV | YGWS { 
| YGX YGXV | YGXS | 
| YGZ { YGZV. | #£YGZS | 
i ZZA | ZZAA i None | 
| Z2B ! ZZBA i . | 
| ZZC | ZZCA . \ 
; Z2F | Z2FA | : | 
Ma ee eee 
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Indexes to program logic manuals are consolidated in the publication IBM System/360 


Operating System: Program Logic Manual Index, Form Y28-6717. 


For additional information 


about any subject listed below, refer to other publications listed for the same subject 


in the Master Index. 


(Where more than one page reference is given, the major reference is first.) 


‘anchor word’ 46 

*bootstrap’® routine 20 

"call sets, 25 

"check bit (EMCH) 63 

"complete bit' (ECMP) 63 

"complete bit’ (event variable) 62 
*mother-daughter* relationship 59 
"extended search’ feature 39 
"soft" code 55 


A format items 81 

ABEND macro 43 

abnormal return 79 

abnormal termination 70 

abnormal-end-of-task routine 61 

access method interfaces 
CONSECUTIVE data sets 


BSAM 34 

QSAM 34 
INDEXED data sets 

BISAM 35 

QISAM 35 
REGIONAL data sets 

BDAM 37 

BSAM 37 


additional access modules, record I/O 32 
address of current LWS 44 
addressing interrupt 66 
ADV (Array Dope Vector) 
ADV field definition 183 
aliases of modules 247 
alignment, (fixed/varying strings) 79 
alignment of modules 177 
ALL (arrays) 84-85 
ALLOCATE statement 45 
allocation request 46 
alternative I/O modules (multitasking) 63 
ANY (arrays) 84-85 
APLIST (parameter list) 57 
area storage for based variables 48 
area variable 48,227 
area variable assignment 48 
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